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This document marks a milestone in the evolution of Electronic Commerce (EC), As we 
have struggled with understanding the requirements we have found that there are many 
systems and business processes involved in EC. Consequently, there are many differing 
strategies that need to be understood and made compatible and complementary. Version 1 .4 
of this document Is the first step in documenting a baseline and in developing a consistent 
strategy to benefit all the stakeholders. 

This document is the product of many people working together as a team to understand 
and confront the issues concerning the implementation of an EC infrastructure. It will be the 
document used, in conjunction with the Electronic Commerce Directive, to manage the evolving 
capabilities and opportunities that surface as we endeavor to make our government more 
efficient in this era of scarce resources. 
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Deputy Under Secretary of Defense 
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1.0 EXECUTIVE SUMMARY 



nnrfrnS^L Sn,?9 the paper ess exchange of business information or ideas using Electronic 
Data Interchange (EDI), Electronic maU (E-Mail), electronic bulletin boards, Electro^rSlWer 
(EFT), and other similar technologies. EDI, a primary metiiod of conductin- E^C iX 
computer-to-computer exchange of business transaction information in a pubUc ^Sd format 

The federal vision of EC is a result of the President's direction that the implementation of electrnn,> 
commerce be accelerated across the Executive Branch of the Federd aoTr^wf SdoD ^ 
EC is to develop an electronic enviiomnent supported by a st^nd^^S^c f^dS^Zc °^ 
commerce that enables execution of the national miUtar>r strate^AiSs neSme tET 
mobihzatioi^ and warfighting sustaimnent This will^ur^'SpSSTblemtiSEC 
throughout the business processes of the Federal Government "^^'"^^"^ ^ mtegratmg EC 

The purpose of the DOD Electronic Commerce (EC) Requirements Svstem.^ W /mn/^m^^.^^^ 
^/.-aregydocument is to estabUsh a common DOD EC visV^bTS W iJS^ 
responsibilities, and strategies for achieving a unified annroach to Fr;mJw3™S^ ' i • r 
addition, it serves to document the current^dfo^^'PPS^^^^^^^ 

m'rn Tt ?f 1 """T ^""^^^"^ §^ouglX'iSfe^TM^^ 

(DII). It IS an evolving document that is intended to be updated periodically to idS chanSsS 
requirements and the strategies that need to be tailored to MfiU those requiremlS^ ^ 

(WWW). Another is postmg government requirements (business oppornmitils) on &e^^ whirl 

nif S °" '^^^^ jailabie commercial electronic forms tectootoS^ S provfdesT^' 
person-to-machine" mterface for DOD contractors. proviaes a 

This document is a management tool to be used to describe the evolution of EC throughout the fed^^F 
government It identities existing fiinctional. and infrastrucmre capabilities issuerSnomL-^^^^^^ 

Ec'from bo'Sf^t^r^^^^ ^ T ^^'^^ government It depict? the ^ScS^SH^'^^^^^^^^^ 
t-u, irom oom the DOD and civilian asencv Dersnectives It Hplmp^or^^c -.t o i r "t^"*"*^^ rcucrai 

fumrc «qui— for EC implementidons 'wiSoD L'cS iSncK^ 

1 ne information contained herein is available at multiple levels of detail from the hiah level overview 

» Of *e d^S^d'Sr 

To ensure there is a common understanding of what is addressed in this document and what is needed 
from the organizations that are panicipating in its development the followinrdeflm^oi^s a?e prSv^ded: 

^1S!}.?TT' • functional requirements for the infrastrucmre that will suooort the 

mission, goals, and objectives of the business communities that are or anticipate using EC 

^^A^J^ffT 7"^ capabilities of the infrastrucmre in place to support the EC activities that 
are a pan of Federal government business processes. acuvuies mat 
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Strategy- The result or the analysis or requirements and system baselines that identifies considerations 
and recommended actions necessary to transition functional processes, svstems. aoplications and 
delivery mechamsms to an EC environment th^t better suppoits changing missions; ^oals aiid 
objectives. ,o , 

In order to be effective, the overall strategy must address issues such as roles and responsibUities the 
^Som^'Ifd J^nS^^n'^'^A implementations, priorities, funding, schedules, cooperative 

m^st^ffi?fe^?^^ participants m this program must work together to make it work in the 

The evolution of this document aid the underlying strategy it represents depends, to a very sionificant 
extent, on the contmumg mputs from all functional proponents of the Fede^ govemmennhat 
participate m EC. In addition to requirements, system baselines and strategies, the input of references to 
existmg prog^s and documents (such as reports of working groups andlction teaiAs) wi'u Sy 
enhance the effectiveness of this document. These inputs should identify the references and ff 
applicable, mdicate available metiiods to access them, such as a WWW Uniform Resource Locator 
^) or an Intemet File Transfer ProtocolCFTP) address. They will be incorporated into Appendix Y 
of this document and be made available to the Federal community '^hpcuuia 
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2.0 OVERVIEW 



2.1 Purpose 

The purpose of this document is to estabUsh a common DOD EC vi«!inn hv 
It is designed to: 

• Provide consolidated information on all DOD EC initiatives fnr.,c*K«^,,o* 
program managers, poHcy makers and commandeiS^ ^ 

• getine the roles, responsibilities and relationships of participants inEC and FDT 
. Identify the core components of the DOD EC inLstrSctiie 

• {^ocument migration and implementation paths for EC and EDI 

• SeSlS>vS"'"^^^^^^^ 

duplication of efforts ^ ^ utilization of assigned resources and preclude 

• D^cribe initiatives to eliminate impediments to the re3I1•7n^^nn/^fT:/-• : 

S:^^?— deS - EC from 

suppon the Draft Directive ^d c^^ufiS^au rSl^^^^^^^ fr ^""^ 9.°° organizations will 

the Militarv Services, DefeiSi A^cies OSD^Sn.fq I^^a'"'^^^ framework for 

communities, and ^vi^l be u^dltel bS on t^^^^^^^^^ ^T^^^^ 

representative of the DOD Ex&cuuyfT sa^ntf^^vf. ■ ^ ^rmcipal Staff Assistant for EC, and 

Secretary- of Defense??cqdS ref^^^^ [ySD(A&T)], the Deputy Under 

Director. DOD Electronic CoZercrmUsSr^^ ^^J°i"^ ^ffo^s of the 

.Analysis ( DISA-D7) in the ex^rion of thfs st^^i^^^ """^ ^'^"^ Requirements & 

2.2 Background 

Exhibit 2.1 summarizes the maior events in the evolution nfPr an^r cnr • r j , 
the early 1960s, the DOD developed th^Mill^ SmnS^^^^^^ the federal government. In 

the EDI technologies that we empTv todav ^^^^^ Precursor to 

Committee (TDCC) beaan the devefoS of rnev^Pnr J.n^ Transportauon Data Coordinating 
length records and be flexible to suopSwpL b^^e^^^ ^^^ble 
trorn the private sector, the AmericiA Nation^^Sds iS^^^^^ T""'"' ^^^"^^^ 

1 979 as the US national standard for EDI. '^'^"^^s instimte (.ANSI) X12 standard emerged m 
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EVOLUTION OF EC/EDI IN THE D 
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Exhibit 2. 1 - Evolution of EC and EDI in the DOD 

For many years the DOD has advocated the use of EDI technoiOgy to improve its operations" and the 
ervtces provided to its customers. A 1988 Deputy Secretary of Defense memo, addressed t^tTemilltarv 
services and-agencies, solicited maximum use of EDI, based on ten years of DOD EDI experiences 

In July 1993,the Deputy Under Secretary of Defense (Acquisition Reform) chanered the Electronic 
Commerce In Contracting (ECIC) Process Action Team (PAT) to conduct a bonom-up review of 
existing and ongomg use of EDI technologies in Defense procurement svstems. The ECIC PAT with 
representatives trom across the DOD and advisors from Federal agencies and the private secior ' 
developed an implementation plan for an integrated DOD-wide approach to ECIC. 

In September 1993, the National Performance Review recommended that EC and EDI be expanded 
within the federal acquisition system. ^ 

In October 1993, President Climon signed an Executive Memorandum directing the broad and ranid 
implementation ot EC to supoon a full scale Federal EC system that e.xpands ii5tial capabilities tb 
include electromc payments, document mterchange, and Federal purchases. 

The Congress, recognizing the potential for savings and process hnprovement in the Federal 
fr^nfi;;;;?';- "^^^r^ "Trf^fr P""^^^^ ''"^"^'^ governmental use, required the 

S™?!SiSna°Ac?^f i^lf procurement actions in the Federal Acquisition 

Because international trade is becoming increasingly common, the ANSI X12 Standards Committee has 

*e United Nations EDI for Administration. Commerce and 
Transport(UN/EDIFACT) standards to ensure interoperability. Tnis alignment will begin in 1997 and 
will lead to the achievement of a single global EDI standard. ~ 1 77 / ana 
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23 Organization of the Strategy Document 

This document is organized into five maifi sections and a series of appendices. ' " 

The Executive Summary provides a high level overview of the document stressina the m«in iA^. 

d™: ^'^'^^^^ '^^j- oTn.d ^the 

The Overview section discusses the purpose, background, and vision for EC within the FeH^«,i 

and include «f«ence3 u> specific Actional requiS fo^&J^S^.Sfpm^"^. 

The Systems Baseline section describes the scone of the non pr ;«frne^,^^ j • i ^ 
d™„ of how DISA has cuftcntly =o^|S^^ S.c^gS InfoSSl^^S^ mfn'.^ 
support both the generic requirements and spedfic DOD and CiS^gSS^T.S?S^ 

implementations, resource priorities and funding issSes. estabhsh and support 

The appendices contain more detailed analyses of snecifir rf.n,i;™rr,^^t,. f« .... 

planned or in progress. It is intended tS^ro?/^^^^ fnfoS.'f 

This w,U facUitate the capability of DISA to undlSL^ re^nSo'tS^^^qS^*"' 

2.4 Electronic Commerce in Contracting Vision 

&fs:°.is^-s^ 

assmnpfons, principles, goals and objectives will allow the Sem of vS 
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lntern<8t (WWW) 




01 o suiis-ni 



NIPRNET 
(DoOr-lntranet)- 






Exhibit 2.2 - EC Vision 



2.4.1 Assumptions 



.As show,-n in E.xhibu 2.j the evolving EC infrastructure will support the tlow of these transactions via a 
variety of paths. Tne tollowing assumptions must guide the DOD EC Infrastructure and the use of it bv 
^■tS^v™^ Because the DOD Nonclassified Internet Protocol Router Network 

(NIPRNET) and Internet are interconnected, the Services and Agencies will have options to* 
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Exhibit 2.3 - Evolving EC Infrastructure 
' iTj^l'ft the NIPRNET and make use of the Electronic Commerce Processina Node (ECPNl or 

• ^^^^ - ^-ted 

• tou jrth^e'ln^^^^^ ""^ ^"'"""'^ "^''"'"^ procurements directly to DOD cenified VANS 

' vifcadS^^^^^^ DISN/FTS2000 and pass transactions directly to DOD cenified 

' Internet ^"^^ '^"^'"^ accessible through the NIPILNET and the 

2.4.2 Principles 

The principles of the DOD EC and EDI program are to the maximum extent practicable: 

• Utilize EC/EDI to enable business process reengineerins. EC practices that imoede business 
process reengmeenng or improvement should immediatelv be brought to SenLno^^^ PC 
Executive Agent, who shall take immediate action to resolve anv sufh issue ^ 

I PrpSnr^° "1-^'' f soluuon that vyill prevent utilization of new iechnologv to accomplish EC/EDI 

• Present a Smgle face to mdustiy" (one time entry into a svstem bv a vendor) when solStS^ 
vendors, requinng connracror registration and receiving ceftificatidns a^d repre^Sfot^?^ ^ 

• Ose the same data, without reentry, in all functional areas (e.g. Contraciina FinS 
Transporution. Medical) ^ono-acimg, tmancial, 

' ?.Thn>"° org^ization to ^ansition to an EC architecture that does not meet or exceed the 
. L^hS th?A%??'V^^^^^ r '""^ "5"^^^ organization 

EDIfIcT s^a^dar^ transactmg business, migrating in the fumre to the L^N 
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The goals of the DOD EC and EDI program are to: 

' SJ^'ii;?/P°f^'^^'^ Contractor Registration (CCR) capability to do business eiectronicallv 
Sl^t'^So'rS^^lc'^'"^^^^ "'^""^^ "^^^^'^ ^-^-^ Electronic Conanerce SqS 

• m?I^n?p'S^f PT?;*^°^ of implementing the national (ANSI X12) and international 

• Modify existing legacy systems to be EC and EDI capable 

• Estabhsh an Electronic Commerce Information Center (ECIC) 

• Use the Acquisition Reform Communications Center (ARCC) for education and outreach 

• ^::^oIoY;^t '''''''''' 

• Allow Federal contractors not using EDI to benefit from EC by accessing aovemraent 
requirements (busmess opportunities) through the World Wide Web (WWW) 

2.4.4 Objectives 

The objectives of the EC and EDI program are to: 

. Improve efficiency and lower costs by simplifying and standardizing procedures for oroces.ina 

• r*^"" '^boi^^costs by decreasing the amount of manual processins required to do business 

• Reduce costs by decreasmg required inventory levels due to shoner acquisition lead-time 

• Provide more comprehensive transaction history and stams information for management deckfon 
. makers by providmg automated audit trails for events such as datc-'time receTp^s^ess^^^^^^^^ 

• Eliminate duplication of effort and resources by migrating to a centralized intrastrucmre which 

' coZ^r^" Federal-wide manual and duplicative registration process for government 

• J'^^I^^^Ofi^i^oP information resource for Governmem EC information 

• ^f^^l^f ^»"^t'^"°'^^'zed "Pability to educate and train the work force and trading partners on 

. Provide an interoperable electronic environment that reuses shareable data across functional areas 

An important concept in implementing EC is the goal of achievins a "sin'^le face to indn^rv Tt ma,r,e 

Pr^^"^.-.^insl« in^rface to comme^id p^^^^ 

c=S^^^^^^^^^ 

• ^^^^ 

A^ 4V^?wh>l"''^ '° """^ °f *e "^^y DOD-cenified Vafue AddS^et^orks 

ki'^rl V^i*"^ ^T''^^ connectivity to the infrastrucmre i^etworks 

. The DISA Compliance Test Facility (CTF) will perform certification of a trading partner's 
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capability to comply witii Federal Govemrteht EDI impiementation conventions. 
2o Definitions 

There are many similar, yet differing, definitions of EDI and EC beina ii«*.H th«>.,„i,«.„ .u 

^Sl^S^^o^' co,npu«..o.o„,^ exchange of b^i„e« «„^tion 
example, E-Mail can be created on-line and sent MsoraMS^Tlfe^SS^?/ ^ documents. For 

accomplislied elecnoniially wiS papS and/or end of the exchange, the exchange itself is 

^I^Z^^ c=^;"/lPvirrt ?— -hat serves to 

' RELATIONSHIP BETWEEN EC and EDI 
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These are stnct definitions in the sense that EG is, 'paperless' and EDI is bound to a 'public standard ' Of 
couree, while there exist a number of irisfSnees Mere information is exchanged electtonicaUy much of 
this data exchange IS done usmg proprietary formats that are not generally avaUable to the public This 
strategy for EC and EDI within DOD focuses on the migration toward ushig the A^wiSn National 
S^dards Institute (AxNSI) Accredited Standards ComnS^ee (ASC) X12 EDI ^Sf^IlfSess 
transaction interfaces which analysis mdicates benefit can be derived, both inteinally within DOD Sd 
externally with other governmental agencies as weU as the commercial sector. The OTate^^v also 
recognizes that the international standard UN/EDIFACT is used by some Federal agencies and the U S 
XI2 standard is expected to be aligned with it in the relatively near future. DOD w3l suppon the 
SS. vfo^P^ff ^"^^^ ? ^- activities that it is supporting. In the remainder of this document the 
term XI2 will be used to unply whatever standard is appropriate for the implementation. 

The following definitions are the foundation for the basic understanding of EDI concepts 

Ti2ding_Parttieis- Entities who acchange busixiess transactions^ 

Trading Partner fExtemal)- A non-Federal Government entity witii whom the Federal Government 
exchanges busmess transactions. 

L'^^^'c?"^!'^?"^^'"'^'^ " ^ ^^^^"^ Government entity who exchanges business transactions witii 
another Federal Government entity. 

Traiisaction Set - A semantically meaningful unit of transaction information exchanged between EDI 
trading partners. It can be thought of as the electronic counterpart of a paper document that represents a 
ti^action, e.g., an invoice, a bill of lading, or a medical insurance statement. represents a 

Transaction - All of the business information contained in a transaction set. 

SSJilJ&^^^^V;^ cransaction that, rather than being sent to one trading parmer. is broadcasted to a 

K 1^'°''° f "^i- '^^'^^^^^^^V' a transaction that is made available to anv tradina 
partner by bemg placed m a publicly accessible media, such as an electronic bulletm board for 
uowmoauing. ' 

Implementanon Convention - A subset of the X12 standard that represents the common practices and/or 
interpretations of the use of XI2 standards. Conventions define how tradina pmSS^U^e the 
standards to accommodate their munial needs. " 

DOD EC and EDI Infrosimcmre - A subset of the DII that is designed to support EC and EDI It is 
composed ot haraware, somvare and people. It provides services'such as trkJisiation. archivincr 
dtstnbution. and result notification. It suppons all DOD EC and EDI functional activities as well as 
otiier civilian agencies tha;t may need to use it. 

FACpI- Federal .Acquisition Network was created bv Section 9001 Federal acauisition StrPiTnimino 

Elec?rnn?'k'"'- ^' '^r''^ ""'^ ^'^^ ^^^^ ^AC NTT is delSd'LTrSov^^ 

E ec^omc Commerce^lectromc Data Interchange (EC/EDI) systems architecmre for the acquisitbn of 
supplies and semces tiiat provides for electronic data interchange of acquisition infomiation between tiie 
Government and the pnvate sector, employs nationally and intemationallv recognized data formats and 
provides universal user access. F.AR 4.50 1 ' ~ "'^^'^ dna 

Interim FACN-ET means a contracting office has been certified as having implemented a capability to 
provide %videspread public notice of. issue solicitations, and receive responses to solicitations and 
associated requests for mformauon through FACN-ET. Such capabilitv must allow the private sector to 
^"^.^s 01 solicitations, access and review solicitations, and respond to solicitations 

V? w a"°' • T^T ''"^ ^ of capabilities. For procurements at or below die 

Simpliiied Acquisition Treshold, a contracting activity using an Interim FACNET certified svstem is 
exempted from the requirement of posting or synopsis in die Commerce Business Dailv (CBD) as 
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soUciSfoi ^""^ ^^^^ """^ ^"^"^^ ^'^"^^^^ ^'^^'^ ^^^^ Of 

Exhibit 2.5 identifies some of the EDI edtiipbaeiits in a cfoss-fiinctional imoiementation of Fnr 

represents a conceptual example of the vision for EDI in DOD tS 

anci finance functions by passLg X12 transactions a^ong v2S^ ^r^s'^^^^^ 

well as the external commercial entities involved in the orocess of ;irn,,;Sn<,^«2?^^ 

example shows the entire process beginning wSh ^rSmSoTa^d tnrf^^^^^ """^ '^"^u"'" • 

Internal to «xch of these aSivities are^lterfrSTS^l a^^^^^^ 
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Exhibit 2.6 -DOD EC and EDI Strategy Timeline 
The version dates and contents are described below: 

• 17 October 1996 -V l.O 
Appendices vvill include the detailed EDI Baseline, and Strateav documents for DLA Finance and 
Accountmg, Transportation, DOD Small Procurement, Medicil Logistics and Uie Federd 
Agencies as provided by the functional community. ' ui^rcucroi 



• 31 .A.pril 1997 -V 2.0 

r^d SSraeaS ""^'^ "^"""^ ^^'^^ '^'^ Transportation, additional functional 

• 30 October 1997 -V 3.0 

Information from V2.0 plus more details and additional functional areas with strate'^ies. 



areas. 
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3.0 REQUlREMEiNTS 



This section identines the in&astructure characteristics that are normally required in an EC and EDI 
unpleinentatipn and descnbes elements which need to be elaborated during program or proj^t 
detimtion. It mtroduces a process which can be used to ensure the businesJreqiSementi ai identified 
recorded, and saQsfied.lt refers the reader to documents of specific EC and EDI projertTf^wW^fa 
requirements are known or being developed- t'fujc«.i:> wr wmcn 

The existing Defense Information bifcistrucnire (DII) satisfies many of the requirements for moving 
electromc transactions between trading partners. There are, howeve?, specific ^equSd ^an^S tSlre 
not cmrently Identified or supported by DH. Hiis document encourages the conSn oSSn 
firom readers to assist m the identificadon of additional features req^d to conSct EC 

3,1 EC and EDI Infrastructure Requirements 

requirements for EC and EDI are derived from the DOD Electronic Commerce in Contractina 

SreTpA&J m.?on^^^^^^ * • ^'^'^ Streamlining Acquisition through SSc 
ii^^^cmre- P^^* ^® «»"owmg basic reqmrements apply to the Federal EC and EDI support 

Functionality - The infrastructure must be capable of supporting the following functions required to 
process and transmit transactions electronically: uwua ic4uucu lu 

• Translation of user defined files into X12 transactions and decode X12 transactions 

• Providing directory services required to route transactions 

• Validation of trading partner information 

• Compliance testing 

• Acknowledgment of unsuccessful processing 

• Archiving of data ^ 

• Provide for accounting and billingservices 

• Provide for query andlrouble reporting capability 

Cencrai Contractor Registration^ The infrastructure must provide a fiiUv operational capabilitv for 

» include .0.. 

• pJobkmf'^^'''^^ ^^^^"^ required to ensure data recoverabilit>- in case of hardware or software 

. Provide Continuity of Operations (COOP) capability to reroute transaction workload durina 
standdown of an mfrastrucnire processing node or communication channel. * 

Security - The infrastructure must provide security services that will: 

• rffori?//°^'^"'"-'"*^ mechanisms to ensure security equal to or greater than that currentlv 
afforded to transactions m the non-EC environment. This includes maintaining the inte-rir/'of the 
data contained svithm the transaction as well as safeguarding the data aaaiSisdoSrel^^ 

• • nof h. ?ff^!ljT?- '"'^TT- '^^Lf °' °^^>' of the^oriainal transaction should 

not be allowed, but must be detectable if it occurs. 
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• Provide procedures and mechanisms to protect inJiastructure hardware, software, and data from 
tampenng or unauthorized access. . ■ '■^^i-'^^ai 

* Provide procedures and mechanisms to positively identify the transaction originator and recipient 
Misrepresentation ot the ongmatiiil/fbiieiving party must be detectable. 

Developmental Testing Support^ Tht infrastructure must have the capacitv to suppon the testin<T of new 
mipiementanons and prototype developments while preventing interference yn^lrod^^on^l^Z 

End-to-End Reliability - bifcisttucmre users must be assured that their transactions will be deUvered to 
the mtended recipients. The infrastructure must include procedures and mechaniSr notiW^e:^ 
of undehverable transactions (e.g., unidentifiable address). "«^j>u«, lur noaiymg users 

Auditability - TTie infrastructure must provide a transaction audit trail which allows infrastructure 
operators to follow the status of a transaction as it traverses the infrastructure and to reconstruct the 
times of transaction events after a transaction has e.\ited the infrastructure. 

Scalability - The infrastructure's architecture will be scaleable to facilitate rapid expansion in order to 
accommodate additional transaction workload. At^auiiun m oraer to 

£/je o/D/7 Componenrj - The infrastnicture must make maximum use of ex^^ 

components of the Defense Information Infrastructure. «"w«m. 

Use of Off-TheShelf Products - The infrastructure must make maximum use of 
Commercial-Off-The-Shelf (COTS) software and reusable Goveniment-Off-The-Shelf (GOTS) software 
products that have been tested, accepted, and are configurable and/or supportable by the GoverSJ^ 

Data Conventions- The infrastructure will only transmit Federal Govemment-approved implementation 
conventions which are based on X12 and/or EDIFACT standards. «ipprovca implementation 

3.2 Requirements Identification Process 

I]'n5?^*-''°'^ ^or DII Integration, shown in exhibit 3.L is a methodolosv for handling a wide variety 
ot DISA requirements. DISAs customer (or "user") organizations generaw the majoritv~of DISA 
program requirements The DII receives and implements these requirements. The Requirements Process 
and Its supportmg tools structure is the mechanism by which user needs are integrated into DII 
programs. ~ 
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Exhibit 3.1- Framework for DII Integration 

DISA requirements are typically identified by three sources: (1) DISA D7 Integration xVIanagers;(2) 
DISA Customer Representauves assigned to DISA Directorates other than DISA D7- and (3) 
Cross-Functional Requirements resulting from maturation ofthe System Interface/Data 
Exchange(S17DE) and the identification of Base Level Interfaces to CINC/Service and Global Command 
and Control System (GCCS)/Globai Combat Suppon System (GCSS) proerams. The process tracks the 
evaluation, documentation, and disposition of requirements identified by the three sources. 

3.3 Requirements Process 

The general EC and EDI infrastructure characteristics described above will be analvzed in the context of 
DIbA's current and future capability to meet specific requirements ofthe Federal user communitv The 
user requirements collected are presented in the appendices to this document. As pan of document 
evolution additional requirements wll be collected and the appendices will be updated. 

Section 4. 1 focuses on the current DOD EC and EDI infrastructure, maintained bv DISA, with the intent 
to baseline the inirasurucmre's functional and technical support capacitv. Based on that capacitv versus 
the required capacity, the implementation strategy will be developed Issues and recommended actions 
will also be developed and maintained in Appendix X. They will be organized in a manner that permits 
tracking the actions. ^ f ^ 

3-4 Specific Project Requirements 

The purpose of this paragraph is to provide references to soecific EC and EDI projects for which 
requirements are known or being developed.For each project mentioned here, there will be an appendix 
containing a shon summary ofthe project. The reader can use that and the referenced requirements 
document to understand the full scope of the project. The reason for this format is to provide a 
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consolidated summary of requirements while avoiding duplication of the detail nf -mv nnrn^„in. 



It should be emphasized that this document is the result of the contributions of the *M,tir^ nnn j 
— '""^r^ and comments and suggestions are welSmed^m J^^^^ tru^t f the 

appendices, which should describe the EDI initiatives from the viewnoint of i!S r^Sls — °f *® 
Staff Assistant (PSA), miUtary service/agency or federal ^en^^ ^^^"^ 

3.4.1 nOD DUSD(AR/EC) 

Use of EC/EDI to suppon DOD procurement processes for amounts of S25K to SIOOK ha<; heen „r,^-. 

consideration for some tune. Tlie Deputy Under Secretary of Defense fAcaSsition R pf^^ 

a ^ocess Action Team (PAT) to assess current contracts caSfestT^^^^^ established 

mfrastructure. The PAT was tasked to develop a comprehfr^We pSr^^^^^ S eI aLro^ch 

for procurement functions that was consistent with X12 standard? kteS DoS 

greatest capability within 2 years and identified relevant poli^Sues ^^^•'^<^^^ P^^^ed the 

In line with the PAT report. DOD identified the organizations that participate in the nrocurement 
process, determmed the types and quantities of busmess transactio^^SLd and fSS^^^^^^ . 
migrate these transactions to the new standard XI2. At th7^?SSfe SsA m^^^ 
llZ.l^^'T'^' for moving these procurement transa~sSh^ e tSf p^^^^^^ 

3.4.2 DOD Finance and Accounting - Unmatched Disbursements 

D0'd''™?^SS SSw/ '"fli^i ^'P^omcm of unmatched disbursements within 
^r^ri' ■ ^ report. Eliminating Unmatched Disbursements - A Combined 4Doroach 

coniammg many recommendations. Several of these recommendations involved SED^Tto imnrnv. 
the situation. The Defense Accountins and Finance Service mPA^^ k ^nZIl, • • '^P'^°^« 

finalized recommendations the EDI fortion ofXS^^^^^^^^^^ 

T]ie requirements that have been developed are being documented in a DISA renmr ^n?j ? j?;- 
^-'-.ffedDisburs^^^^^^^ 

detailed summary of this project can be found in Appendix B to this document 

3.4.3 DOD Transportation 

The repon Defense Transportation Electronic Data Interchange Implementation Plan 4 June 1 9Q6 

Srtl?n''T¥?rn ^° ^-'"'^^^^ impfementation in su™^ ' 

u^s^n^u^nnn^^?l?^.'' """"'^ '^t"'^-"^ ^^^^"^"s toward expandin<^ EDI 

uses m support of DOD transportation busmess information exchances It identifies ba^ic rennfrimln« 

more Ln'l°^^^^ support of DOD transportation in addition to dSl^ig 5ie c^^^^^^ 

more detailed summaiy or this program can be found in Appendix C to this document: ^ 

3.4.4 DOD Medical Logistics 

Medical logistics is a function within the Military Health Services SvstemfMHSS^ au/orM«nH^ 
orgamzation composed of the health resources of DOD Armv Naw Sd SrFori • T 

managed care, preventive medicine, research, and logistics. Medical logistics suonorS'the MH?^^^^ 
essential to patient care m bodi peacetime and wanime. "uutmauon resources 

S!nl^i^?nHn j'!"'^'^^ ^"'"'"^J- ^"PP°" (DMLSS) Program is responsible for definina and 

Sh^^I nilrl^ efficient medical logisucs support enviromnem for health care operarions in pea^etim 
mihtaiy operations other than war, and wartime. Tlie program is composed of tvvo major coSponenr 



11/13/96 8:0t 



(I) development of automated information systems (AIS) to streamline enhance and aummnr<. 
(MLFPIP). which idennfies and .mplements improvement oppominities associated with the teiness 
i^S-^^te »l?dS^r —yof^^ fimction^p'^S^ he 

3.4.5 DOD Procurement 

SSn'iS^ departments, defense agencies, and their components have developed processes and 
busmess practices, mcludmg approxmiateiy 76 unique AISs, to perfonn their procSSSons. 

Stiia*.n?n;J^fS^^^ lecognizing the inefficiencies and costs associated with sustainine 

Syiem fSP?mo^ Z;'^°^T''^ procurement systems, established the Standard ProSm^''^ 
jystem Cbi'b) Program. The SPS Program is iterative and provides the caDabilities and denlovn^St 
^es^hased to correspond with user needs and budgets, for EC/EDI pt^SSey e& the 

eSl P'^""'""'"^' ^ ^"^"^°P«^ ^ conjunction with DOD E^rise data «anSzation 
. a shared data warehouse that will permit receipt and distribution of standardized procurement data, 
• and the DOD Defense Information InfrastructureCDII). 
A more detailed summary of this function's programs can be found in Appendix E of this document. 

3.4.6 DOD Logistics 

3.4.7 DOD Agencies 

3.4.7.1 DLA ■ 

3.4.7.2 rieCA 

3.4.8 Military Services 

3.4.8.1 .A.rmv 

3.4.8.2 Navy 

3.4.8.3 Air Force 

JI^-S!l^'f"/^' Elec'cronic Commerce,/Electronic Data Interchanae Strateav p Julv 1995 
descnbes the Air Force vision, goals, and strategies for EC. The Air Force hai embraced EC aS a w^v to 
improve quahty and reduce cost of operations well into the ne.xt cenmrv. The^^^^F^ce h^s^erd 
Scmer'- "^^""^ summary of these mitiatives can be found m Appendix H of vS 2 of 

3.4.5.4 Marine Corps 

3.4,9 Federal Civilian Agencies 
3.4.9.1 Federal Procurement 
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4.0 SYSTEiMS BASELINE 



TTie section provides a high level description of the EC and EDI inlrastructure maintained by DIS A It is 
F?d^^ove^^''^''*°^ ^^"^^ ''"^ ^° '"^^"^ ^^^"^ available to usere in the 



.Tte first step in expancUng EC within the Federal Government is to determine the current use of the 
mfi^structure m major functional areas. This assessment is used as a starting point for a continuing EC 

^i^^^^' '^^'^ decision/f?r?x/SedT^^^^^^^ 

Most of the current EDI support provided by DISA is in small procurement, where there are already 
several military and civilian activities that are conducting business using the infrastructure in various 
degrees of volume. It is imperanve that current and planned use of EDI by these organizations be 
documented so that adequate fumre support can be planned and provided 

DISA also provides other EC support in the fom of Worid Wide Web (WWW) Home Pages accessible 
via the DOD Nonclass fied Internet Protocol Router Network(>aPRNET) and 4e S^efm?^nno^^ 
no^v includes mformation related to policy, direction and general topics. This stratSy docu^^^^ 
available m electromc format Appendix Y to this document lists mLny related repom aSdXr 

on^'ir/J?. ^^^"^.^^ encouraged to provide additional infonnation regarding 

on-line documents. Other EC support mcludes the on-line trading parmer registration capabUity being 
bmlt mto the Central Contractor Registration (CCR) system. » uuu ^.apdomvy oemg 

^7"^^' ?n ^o^^^^t^'i EC baseline indicates that more functional integration is needed in 

l^^'o fmlS!^.t ?!f warfigh^^co^unlSs T^^ 

lack o f full mtegraaon causes redundancies and duplications that increase the cost of operations thereby 

reducmg the resources available for the DOD warfighting mission. However, sevei^ EDI efforts have ^ 

oeen mitiated wrJim DOD to provide cross-functional iniearatiori within the Defense Finance aad 

Accountmg Service (DFAS), the Defense Logistics Agency (DLA), and TranspoSion 

The remainder of this section provides the baseline of the DII's capability to suppon the EDI portion of 
4.1 EC and EDI Infrastructure Scope 

The DOD EC and EDI infrastructure that has been implemented is comprised of hardware sofuvare 
communications, policy, procedures, and personnel to enable the processing and transmission of ' 
business transactions bet%veen trading parmers. The body of standards governing EDI transactions is also 
mcluded. The key components ot this inirastrucnire are illustrated in E^ibit 4. f below The flow of 
transactions from a DOD .Automated Information System (AIS) to a trading partner (TP) is also shown. 

vsri°?iTv^°'"^ ^f.P^.^^.^V-here electronic transactions are passed from the gatewavs to the 
orocess tl a1 A^^^^^^^ '° tradmg partners Gateways (GWs) represent a front-end 

process to the AIS plaitorm. VANs are commercial entmes m the business of distributing electronic 
transactions to an mternauonally spread customer base. The DISA Compliance Test FacUity fCTF^ 
conducts testing to confirm diat the EDI output files are compliant with appropriate standards and 
hederal EDI implementation convenuons. Trading Partners must successfuUv complete the testin*^ 
requirements and the EDI registration process to become a trading parmer and exchan<»e transactions 
with any Civilian or DOD activity. DUSD(AR) has established CCR to proTde a sSpoTnt Sail 
vendors register wit^ the Govemme.iL The Customer Service Center (CSC) is where ail EC id EDI 
functional, techmcal. configuration and software questions and/or problems are answered/resolved. 
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EC Infrastructure 
^ — • ^ 



Exhibit 4.1 - Boundry of EC Infrastructure 

NEPs, GWs. the CCR. and the CSC are in most cases located in Defense Meaacenters. The network 
connecting EC and EDI components is the NIPRNET. The DISA-managed EC program provides 
funding for the operation, maintenance, and upgradeof EC-dedicated resources in the Defense 
Megacenters. Note that the EC infrastructure managed by DISA does not include connectivity between 
GWs and AISs, connectivity between VANs and trading partners, or the AISs. 

The EC and EDI strategy extends to all participants in Federal procurement. Exhibit 4.2 depicts the 
many elements at the Federal, Defense and commercial levels. Federal EC and EDI is composed of four 
layers: Federal Civilian, Defense, the EC Infrastructure, and the commercial segment with which the 
Government does business. 

In the center lies the Executive Branch and Federal Civilian Agencies which issue E.xecutive Orders, 
formulate policy and create regulations. Also included are the agencies that need to do business, both 
commercial and inter-governmental. Note that EC policy making and regulating are functions that 
overlao into the Defense laver. 



2 of 9 



11/13/96 8 



« 



The Defense layer represents the rest of the Government's business oriented organizations EC 
interactions with the commercial sector rely on and pass through the EC Infrastructure which is 
°P5S^t^^-5^<imaintamed by the Defense Information Systems Agency. The EC Inffast^cmre includes 
SSS-xn^' *^PPii5^"°° Programming Interfaces (API), Electronic Commerce Processing Nodes 
mfcM?' ^^"^'"^ Operations (COOP) services, and the Defense Information Systems Network 



COMPOSITION OF FEDERAL EC AND EDli^ 




Exhibit 4.2 - Composition of Federal EC and EDI 

The overall Command Control Communications Computers Intellisence for the Wanior (C4IFT\V) EC 
and EDI strategv makes use of the centralized network ser^•ices provided bv the Defense Information 
Inirasmicrure (DID, rather than by building its own network infrastructure.'Tne DII is described in detail 
in the DISA docvment DII Master Plan. Version 4.0, dated 26 April 1996. C4I supports the Global 
Combat Suppon System (GCSS) imtiative. This initiative provides a common foundation for 
coexistence and integration of automated information systems to provide combat support The primary 
function of GCSS is to prepare common components of the infrastructure so that the Central Desisn 
Activities (CDA) can develop systems that successfully interface with the common infrastructure." 

To nieet the timelines established by the DOD and Federal EC Process Action Teams DISA used 
existing assets to rapidly deploy an initial DOD infrastrucnire by March 1994. On 30 June 1995 the 
infrastructure was upgraded to increase processing capacitv and' improve speed-of-service This ' 
infrastrucnire is illustrated in E.xhibit 4.3. 
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Exhibit 4.3 - Current DISA EC/EDI Infrastructure 
4.2 Current Capabilities Baseline 

The basic HC and EDI requirements were identified in Section 3. As more specific user requirements are 
i^^""!^f ^.^'^ documented in the appendices, a detailed picnire of required canabilities can be drawn 
Specmc requirements" means dau such as transaction sets, volumes, frequency, timeliness, backun 
andsecunty. » f» 

4.2.1 Functionality 

The NEP and Gateway systems (and evenmally Version 1 of the ECPN) maintained bv DISA satisfv all 
ot the functionality requirements stated in section 3.1 vvith the exception of accounting and billin«» and 
ll^-n'^ ^^SA is in Che process of developing a fee for service structure to include accountin<» 

and billing. DISA is also e.xamining several alternatives that will provide interoperable end-to-end 
directory services (Defense Messaging System (DMS), ECPN. Defense Mesacenter (DMC) DISN 
etc.). - . - V /» , 

ECPN is the result of combining gateway and NEP functions into a sinale environment. New hardware 
and software for this new fiinctionality is being fielded and tested at DMC Ogden, DMC Columbus and 
S^iJl^A COOP and Test Facility (DCTF)in Slidell, LA. CCR functionality will be integrated into the 
ECPN as It matures and will eventually provide the needed directory services. 

4.2.2 Central Contractor Registration 

Central Contractor Registration is one of several major activities that allow the Federal Government to 
present a single face to industry. Begun in September, 1994, its development is in two phases. Phase I 
Identified imtial functional requirements and the database structure, and provided a capability to perform 
initial data validation. Phase II will add several enhancements, including more robust data validation 
EDI transactions (XI 2 824, 838 and 997), audit and administrative functions, and interface software that 
permits on-Ime registration and queries. E.xhibit 4.4 depicts the current CCR registration and validation 
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activities. 



CCR SystemsOvcrvicw 




Exhibit 4.4 - CCR as of xVIarch 1996 



Today, on-line registration is provided by electronically filling in Standard For™ ^1Q. a 

done only by system administration persomiel. For the remaSider lr?\^tl Z in i 

will be enhanced to allow an XP 838 transaction rn nS^L ^ "I® '^^'^^^ registration 

non-Government users to quer^ die svS^S^^^?.^h^^^^^ ^ capabihty for Government and ■ 
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CCR Sy^tfem Overview 
Phase II 
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Exhibit 4.5 - CCR upon Completion of Phase II Development 
-1.2.3 Backup Capability ' 

TTie ECPNs maintainal by DISA will satisfy all of the stated backup requirements. Exhibit 4-6 deoicis 
t be^S^Tm^COOpT^"^^^^^^^^ 
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4.2.4 Security 



Exhibit 4.6 - EC Infrastrucmre 



4.2.5 Developmental Testing Support 

Currently the OSF Developraeni Center and eventually the DCTF will «!,mnnrr , • • 

an operational environment without disturbine theTroduction or^^^^^^ Tnllr r T^'''^ u^^V^ 

Command (HTC) acts as a pseudo-gateway andTseudo Vam K th!. i^" • Interoperability Test 
acoss :he ncnvcrk during ,Li„g ^oZ.'^l^:t^r,^l^^Z^^^ ^ 

4.2.6 End-to-End Reliability and .-Vuditability 
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future 
can be met 



^Sr^' provides an enhanced audit trail of transactions to ensure end-to-ead reiiabilitv and 
^ac'S^^sS^ ""^^ " — ^'^^^S^ notificaSit^^^^ 

4^.7 Scalability 

The ECPN vv^ designed from a hardware, software and communications Dersnective to me^t 
expandmg EDI woridoad. The infrastructure currently handles 23 m^S!Tr,% LT^t^^ 

DUSD(AR/EC) to perform volume testing to ensure that the growing transition demand can be 
4.2.3 Use of Dn Components 

The EC infrastructure design included the use of existing hardware software anW n«.««,„-- ^ 
to process standard transactions. As technology cvoV^± 

4 Use of Off-The-Shelf Products 

The ECPN makes extensive use of off-the-shelf products. Exhibit 4-7 Present ECPN Canahii;t,>^ 
4.2.10 Data Standards 

contigurauon manager for DOD EC/EDI standards. ■:>ianaaras is tne designated 

^r^nZ^f liiformation Technology (IT) Standards Program, the bulk of information technolo-v 
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Present ECPN Capabilities 



ECPN 




• GOTS 

- GCCS SOFTWARE APPLICA 
-GENWATCH 

♦ COTS 
-UNIX HP1 0.1 
-ORACLE 

- GENTRAN: MENTOR 
-C++ 

-XTERM 

-NETSCAPE 

-REMEDY 

-SYSTEM MANAGEMENT T0< 

- OPERATOR TOOLS 



Exhibit 4.7 - ECPN Software Requirements 

Additional information about the specific transaction sets and implementation conventions suoponed bv 
tiie DISA.intrastructure can be tound on tlie World Wide Web at the URL 

h^tD://vv^v^v■iIsi■d^sa■mil/edi/edi.mai^■html . A description of the standards process can also be found at 
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5.0 STRATEGY 



The section describes a strategy to consistently implement EC and EDI throughout the Federal 
GovermnenL It descnbes the actions planned by DISA and other key plavers to ensure that the baseline 
m&astrucnire discussed m Section 4 is prepared to support the requirements of EC and EDI users. 

Topics discussed include roles and responsibilities, an approach to implementing EC and EDI funding 
standards, migration and the development environment v. ouu ciji, lunamg, 

5.1 Roles and Responsibilities 

A firm underjandng of the roles and responsibihties of all of the organizations that are cooperatine to 
implement EC and EDI throughout the Federal government is essential for success. Exhibit 5.1 deoicts 
the core missions and the tecfamcal components that support them, and Exhibit 5.2 depicts the overall 
relationships among the various players that have roles in EC and EDI. 

It is important to note that these relationships are not hierarchical; diey are horizontal, with each group 
of activities contributing its efforts and expertise to the overall EC and EDI program. * 



CORE MISSIONS 
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Exhibit 5.1 - Core Missions 



S^J^f ^ important players in this program are the end users of the results of this effort - the DOn 
eqmpment organizatioS ^ standards, and provide 



Requirements 

Users (DOD Services. DOD Agencies & Federal Civilian 
Agencies) 




Programmatics. Impleme ntation. &Op pratinnc 
DISA, Services & Agencies 



Exhibit 5.2 - Overall EC and EDI Roles and Responsibilities 
5.1.1 Users (DOD Services and Agencies and Federal Civilian .Agencies ) 
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• Users work with PSAs, the DUSD(AR) Director of EC, and DISA D7 in developing specific EC 
and EDI requirements. 

• The Services and Agencies develop Implementation Conventions to XI2 standardsand pass them 
to the DISA Center for Standards for :^roval. 

• Services and Agencies participate in the implementation of reqiiirements mto the DOD 
infiastrucmre by working with DISA D3 . 



Work v/ith the following organizations in developing 

technical EC/EDI requirements: 

- PSAs 

-DUSD(AR) 

-DISA-D7 

Assist DISA Center for Standards in developing 
Implementation Conventions for XI 2 Standards 

Work v/ith DISA - D3 on the implementation of operatior 
requirements into the DOD EC/EDI infrastmcture 



Exhibit 5.3 - Users EC and EDI Roles and Responsibilites 
5.1.2 .Acquisition and Technology USD(A«S:T) 

Tne Under Secretary of Defense for Acquisition and Technology is the DOD Executive Aaent for EC 
provides oversight direction for EC and EDI. In that role, the USD(A&T) coordinates the development 
of functional area EC and EDI implementation plans and provides for resource management.See E.xhibit 
5.4.The Principal Under Secretary of Defense for Acquisition and Technology facilitates the 
reconciliation and resolution of cross-functional and inter-Sefvice and Agency EC issues. 
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5.U Acquisition Reform -DUSD(AR) 

The Deputy Under Secretaiy of Defense for Acquisition Reform [DUSD(AR)1 is the PSA 

for inseraon of EC technologies across DOD. lusjou^^)^ is me t-bA responsible 

^H?r!^l°Hi'^^H^ ""^P'- ^^"^^""^ for aU joint DOD and Civilian Agency initiatives and for the 
S?.nt"^^''"i^ir^^'?^?'''' of legacy systems to accommodate EC and EDI. DUSDf ^^^Wsn fi^^^^ 
DOD's EC and EDI mitiatives that are within the scope of the DOD EC and phY r^^^^^ 
the correction of EC practices that impede BPR. ^ P^^''^ facilitates 

ACQUi SITIONAND TECHNOLQG Y 

E C A N D E D ri:R 0 L E S;::V A N D .R E S P 0 N S I B IL ITIE S 



u so rA& T 1 

- The 0 0 D E xecutlve Agent for EC 

- Provide EC p o lie y direction , 
oversight, resources m anagem ent. 
and coordination o f req uire m ents, 
and develop and maintain a 

DOD -wide E C im plem entatlon plan 

- R eview im plem enting docum ents 
supplem enting the E C Directive 

- Advocate and provide the necessary 
budget authority to support 000 

d trected initiatives 



P 0 U S D rA .2 T 1 



Facilitate the reconciliation and 
resolution o f cro s s- fu n ctio n a I a n d 
in te r-S ervice and Agency EC issues 
forthe Departm ent ofD efense 



D U S 0 rA R 1 

-PSA responsible for insertion of E C 
in all developm ent, m od ernizatio n , or 
prototype of legacy and m igratlon 
system s as nom Inated by the P SAs 

- Fa cilitate coordina tion offunctional 
requirements for EC initiatives 
aero ss D 0 D 

- Approve allJointDOD and Federal 
civilian agency initiatives funded by 
0 SO 

- Facilitate the correction on any EC 
pra ctice s th at im p ede BPR or 
process im p ro ve m ent 



' Exhibit 5.4 . Acquisition and Technology EC and EDI Roles and Responsibilities 
5.1.4 Director, Electronic Commerce 

Under the DUSD(.AR) is the Director for Electronic Commerce (DUSDC\R>EC). See Exhibit 5 5 The 
Director provides a leadership role as the EC and EDI facilitator across DOD and provicS 
L?frf nnn^ for cross.ftmctional requirements collection and inteara^on.^^^^^^ 

as^ the DOD mtertace to the pnvate sector and Civilian Agencies on EC and EDI ftmctional is^^^^^^^ 
cnm^nn-'^ "^f executes business process reengineering opportunities. wor£ Se EC ^^^^ 
community, and develops policies and procedures necessary for EC and EDI. The Director also deTi^ns 
ana implements outreach programs, reviews and makes funding recommendations Vo dS 
new and on.gomg EC aiid EDI initiatives, and provides oversight of approved EC ^d E^^^^^^ 
^s'ems'''"' ^ ^"""'"^ ^"^^^ ^"^"'^^"^ utilizing EC/EDI tecSo^^^^^^^^ 
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DIRECTOR . ELE G TR O NIC C O M M^E R C g 
EC AND EDI ROLES.AND RESPONSIBILITIES 



Facilitate the participation and interaction of th e function a I u ser com m u n ity 
Facilitate the collection and coordination of functional requirements for EC 
across the D epartm ent of D efense > mr c 

Principal point of contact with the private sector, contractors, and Federal 
civilian agencies for the Department of D efense on EC matters 
Principal point of contact with Federal civilian agencies on governm ent-widi 
EC initiatives, systems, policies, and business practices 



Exhibit 5.5 - DUSD(AR) EC and EDI Roles and Responsibilities 
5.1.5 Principal Staff Assistants 

The PS.As to the Secretary of Defense and the Joint Staff establish policv and plan for mission 
Support StS^rls" ^^ requirements for Command and Control (C2), Intelligence, and Mission 

. PSAs determine EC and EDI goals and high-level fiinctional requirements and derive commitment 
trom and provide resources to the organizations to implement EC and EDI goals. 

• PSAs provide direction on developing and deploying EDI capabilities within their purview and 
enstu-e the direction is observed. *^ ' 

Organizations responsible for standardizing business processes and information svstems across DOD 
such as Joint Logistics Support Center (JLSC). Detense Procurement Corporate formation 
Management Systems Center (DPCSC). US TR.ANSCOM (USTC) J4-LT. are chartered to plan 
aevelop, coordmate, and implement improved business practices, and to oversee the develooment of 
automation to support these practices. These organizations are fiinctionallv aliened with the PSAs These 
orgamzations: ' ® "x^t^rxa. luwc 

• Sponsor DOD strategic uses of EC and EDI in their fimctional area, 

• Provide functional input to the DOD EDISMC functional working groups. 

• Assist DOD applications by prt)viding guidelines to create user defined fonnat files OJDF^ that 
can be mappeG to comply uiih federal XI 2 ICS. wt^r; uwl 
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CSD OTSifman JC^ 

- cstadi^ Polices 

- Employ SWeges 

- EnairelmiiiementBtion^ResdvelsajBS 

- Cocrdinate OirBCtcr, DoO EC 

- Resdve Functfcncl Isaacs 

- Provide ttrResdution of Irtegr^ion Issues 

- Prouds Repreartedonto SlanctotS Bddes 
. Develop a Mairtan SWegcEC Pters 

- EstetiWi ange EC Focd Part 



- Prindprt Tectnical Proper^ 

• De«lo|OTertaimp»emertBiimStaixtads 
oasedEDI 

• SjpportRequremertsjasrossFuKScna^ 

^695 

- Tecfriical&SecLirtyConsUtdion 

- Principal Part otCortad-Techncd IssLes 

• Develop Securty Policy a Prooedures 

• E^edish a imidemertJnjOTnedai Policy 

- Oevetopmert 

- Axjuisticn 

• QderGdion 



Conctrdler 

- Rnenceand/tanrting 

- Direction 

- OveracjTt 

- Coorrfnation 



DoOCbmtanftftHyrbp 

- Estabfch EC Componert Focsl Poirt 

- Implemertafai 

- Overeiglt 

- Managemert 

- Cocrdinallon 



Exhibit 5.6 - PSA EC and EDI Roles and Responsibilites 



5.1.6 DISA 



Procurcmem and DISA - D8/JITC Modeling Si-Sulation^SSfo ^ovS^^^^^^ 
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iiup./ www_;.^..;uL' u . ; oninpuos/'strate- 



Punetional R«quirtm«nts 
Cro$$-r unction 31 Intarfaeas 
. 000 

• Industry 

• Civilian A^tneies 
Functional Security Re^^uirements 
R«quir«m«nts Analysis/Integration 

• u ata 

• Infrastructure 
- Applications 

• Transactions 
OSO/S«rvice Liaison 

- Policy 

• Strategy 

- f rogramm aties 



nteqrjtion> 



03 f'Oog ratron^^ 

• Develop Program Strategy 

• Acquire Required Program HW/SW 

• Manage Program Schedule 

• Control Expenditures 

• Analyse Trends 

vSlTditS yfrJlii"^""^ Agreements 
vaitgate Performance 

• Op«rate a Maintain Infrastructure 

• Operational Policy Guidance 

• Operational Policy Comoliance 

• Operate Gateways g h^pV^^ 

NetmTrV Center 

■ rf^aS^^i^V^'^J' Metrics Reporting 

• Trouble Ticket Resolution ' 



Od 



rgnqlneehnq A gtan<4ai>H>^ 



: 8 



Design. Develop. Bu3d. Install 3. Test 
^o'np'jance Test Facility 
-0 0 Representative to Federal. Reaional 
Repositoryfor Standards '^«9ionai. 
Standards Development 
Standards Management Council 
Conaguration Management 



& International Bodies 



0^ flonlstiti^) 

' pI'tSkIII an emotive ILS program 

' li^%ycU fj^j'^^^^^ctt**** to provide 



D8/JITC r gvaiuatian a Tastinq-> 

' f.^'"'? «3st Future Infrastructure 

• Model Future Inirastructure 

• Systems Modeling A Simulation 



Exhibit 5.7 ■- DISA EC and EDI Rote and Responsibilities 

d^^d^^e'&^t-^^^T&'^/^j^*^^^^^^ 

o^feTth»&"t3,te&^^ 

solutions and options whicl, wiU aUmv th^e aSwon ofS;w EC airt ^ 

infrasmicmre. TTie technical archkect coordtaa es beil^n th. ^t^^^ processes to the 

DISA-JIEO stiucnire affectediSinrED?^,?nrt^^^^ vanous subcomponents within the 
secutity (Center for InSatfoi sSs Sec^")^^^^^^^^^ S,an4trds/CFS). 

and Ae^^tSSc&^F^Sg^N^r^l^te^^^^^^^^^ 
5.2 Approach to Implementing EC and EDI 

S^e^reti:^ts=^-SSB 
5.2.1 Identily EC and EDI Functional .Area Opportunities 
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opportunity may represent a need to solve a specifically identified problem, or it may represent a wav to 
mfl^Tr '"^T^ ^"^^''l P^"''-, "^^ "^^^fa^sm for this activity is a high levef OveSn/^pV 

S P^"°^^^^y '9 evaluate candidate oppominities, prioritize Ihem-and pro^e overall 

EC^^U tWs^^ "^^^ initiatives. DUSD(AR/EC), in its role as the DOD PSA 

5.2.2 Establish Functional Working Groups 

ti order to ensure a continuity of focus during planning, development, and implementation of EC and 
EDI projects, functional WorJang IPTs WT) wUl be formed. Each WIPT will SSof 
representatives from DUSD(AR/EC). DISA and the user's organizationfs) wiT oiSS 
representmg both the functional and technical communities, fhev wiU meeTier^oS^dl^TS^^ 
requirements, work out interface issues, and resolve other issues that may arise In c^s-Ll^dcS 
implementations, it wiU be necessary to involve all functional areas in the IPT aSes ^"^""^ 

5.2-3 Develop a Functional Requirements Document 

TTie most impoi^t product of the IPT will be an electronic Functional Requirements Document <TT? 

Sod ^°"r ?,f '"^fe?''^^ ^i^^y assessrS^^tff 2e p^S S 
inWuctuni.It wiU allow DISA to identify what, if any, new technical requiremente are 
needed to support the project's funcnonal implementation. It will also provide information needS to 
develop schedules, implementation conventions, testing requirements, and installaS pl^ 

5.2.4 Determine Priorities, Costs, Budgets, and Schedules 

DUSp(AR/EC) in conjimction with the Principal Staff Assistants work together to develop the 
fimctional pnonties for EC/EDI.The development and enhancement of DISA's h^cS^e is based on 

eJ sTZfa^bafview ^^^^ aTSe co^orate 

levei so tnat a g.obal view of DOD EC and EDI can be mamtamed. resulting in a coordinated effort that 
ha^ high-level visibility and suppon. Estimated costs of the projects are ^xt^M^dS^^^d 
scnedules are developed and priorities established. uucu onu oua^ecs ana 

53 Funding 

JSn^fM ?^ °^ Of Defense Principal Staff Assistants, Services,and Agencies 

should fund implementation of EC so that, where it is appropriate, the Departments paper-bS business 
KS'?rn EC technologies. "ITie Components and their respective Program Ex^Stiv?^^^^^ 

should allocate sutficient resources to ensure all migration and new starts are m^ll comSce wi^^^^ 
standards Components should continue to implement and expand the EC proi^ in aU ^oXrS^ 
runctioncJ areas and ensure practices are compliant with EDI standards. cLoorSiLS Sue to 

vS^rh'^ nnn°' ^^"'^"'^ ^''"•^ '° •^'^^^ Deparmients abiiiH ?o exchange in^^^^ 

withm the DOD, with other government agencies, with allies, and with industK'. mroimaiion 

Currently, users of theDOD EC and EDI infrastrucmre are not required to reimburse DISA for that 
usage. Begmmng in FY99 customers xvill be required to reimburs2 DISA foTSe^rfie EC/H^^^^^^^ 
intrastrucmre on a tee-for service basis (Defense Business Operations Fund (DBOF)) DISA is working 

5.4 Services and Agencies 

Services and Agencies will be responsible for maintaining their functional aoDlications orenarina them 
for interfacing with the DOD EC and EDI infrastructure, 'raining operSnfSctk,^^^! 
and mamtaimng the hardware platforms that host their applications iu^i^uonai personnel, 

5.5TiVIigrating to Future Infrastructures 



Sot 10 



11/13/96 8:1 



I i tiu .. . 'V vv w . u : ;. . : : ; L / / 0 n 1 np u OS/ Strategy/ s 



pis A is currently engineering a more efficient infrastructure which will co-Iocate the NEP and GW 
^l^'ZZ Electromc Com^^ Processing Nodes (ECPNs) and standardize the services provided at 
each processing site. DIS A is now deploying the new architecture (ECPN Version' I 0) Exhibit 5 8 
depicts this new EC/EDI infrastructure architecture. ^' ^^-^oit j 

Capabilities diat are built into Version 1 .0 include: 



Increased user transaction capacity 

Enhanced communications 

Stable and reliable processing code 

Hardware architecture designed and optimized for EDI tasks 

Fully accessible audit trail and reporting tools 

Research tools provided to customer service center 

Multi-strategy Continuity of Operations Plan (COOP) 



The outyeararchitecture will evolve as the Common Operating Environment (COE) and supportine 
common ii^astmcto^^^ For instance, the DMS will be used to provide standard messages to 
elements of die COE ait^^ DMS reaches Initial Operating Capability (IOC). Use of DM^Se 
mtegrated mto EC/EDI^perations. More transparentiy, EC/EDI rides whatever transport layer is 
provided by Ae MPRi^^^ As NIPRNET evolves, EC/EDI will make use of its expSc^Tapa^bilities 
eS vf^S infrastructure beyond FY96 (witii ECPN Version 2.0 implemented) is depiSin 



Capabilities that are built into Version 2.0 include: 

• Data load leveling 

• Transaction error identification tools 

• EDI infi^tructure viewing tools 

- Filtering by Service/Agency 

- Filtering by industrial sector 

• Statistical analysis on transaction sets 

• Automated repon generation 



DCO 
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Exhibit 5.8 - Future EC/ED[ Inirastrucmre 
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APPENDIX A - DOD DUSD(AR/EC) 



1.0 Background 



mnn^ (EC)/Electromc Daa Interchange (EDI) to support Department of Defense 

(DOD) procurement processes has been under consideration for some time A 1988 DepuS^ Secre^^^ 
Defense memo called for maxmium use of EDI, based on 10 years of DOD EDI invesSation Sd 

'f''' ""fT "^^'^'^^ Decision 941 sit^^ie s^tfSal o^DOD's 

current efforts is to provide the department with the capability to initiate, conduct, and maintain ils 

r^S^g'r^e^ o?S^^ c^rdS-^'^ "^^^"^ "^^^ actS^^^hout 

rni^ISK.!^^' £2°/''^!^?'^°° ^^"^'^^ (S^'^^O'^ SOO) Panel submitted a repon to 
Congress that concentrated on "changes that would streamline the defense procurement p?ocess in the 
1990 s when dollars are expected to be fewer, work forces smaller, and superpower sectSry tSeatsIess 
urgent." Among the hundreds of recommendations contained in the report were seveSl STadd?e2ed 
^ PcTX'^.n'nJ^^^^^^^ procurement notice and contracting meSiods. TTie rapS^im? emSon 
?^ J? ^ n°? acquisition reform and the recommendations contained in the 

Streamlining Defense Acqmsmon Laws Report, particularly the recommendation to raise the small 
purchase threshold to a 5100,000 simplified acquisition threshold. EC contaS Ae iXe^Lt cS to 

^^Zfj^T'' '^'T^' "° -^"^ ^^^f^ ^^^^^^ ^° DOD procurement inforiTt oXS 

busmesses. It represen^ a vast unprovement over the manual svstem that is currentlv in use Therefore 
EC and the associated DOD EDI architecmre are vital to the reform program ™onSoS sS^^^^^^ 
of many other acquisition reform initiatives. ""u v-uusici^ionai suppon 

On September 7, 1993, the National Performance Review (NPR) recommended that EC/EDI be 
expanded withm the federal acqmsmon system. One of Vice President Gore's recommendations for 
procurement specificallv calls for estabh-shment of a Govemment^wide prosram toTe EC for federal 
acquisition below a specified dollar threshold and for those acquisitions^-oTde s St use simS 

SSSn dSd ' '^'"^ '^''^^'^^ ^^^^ ^^PP°" exp'iSfon 

Colleen A. Preston,Deputy Under Secretary of Defense (Acquisition Reform) has taken definitive -irrmn 
on these proposals. On July 22, 1993. Mrs. Preston directed Ihe ChainnS^^^e C?^^^^^ 
Management (CLVp Procurement Council to establish a Process Action Ter^?AT)^to^sesicJSJm 
con^cung capabilities m Je DOD ECJDI inWucmre. Building upon curTen^D0D?4aS^^^ 
DOD EC m Contracting PAT was tasked to develop a comprehensive planfor implementii?^ an EC 
xF'^^^t^T'iiT'^^''' =°'^.'s«nt with the .American National Standards Institute (ANSI) 

rdev^Tpo^cv issued ' " '^'^ ^^^""^^ 

The EC in Contracting P.AT membership reflected a broad cross section of Militarv Services and 
Detente .-^gencies working on a tull-time basis for 60 days. The diversitv of the EC in Contracting PAT 
So? I^f i^'^"^ °f ^1 DOD components were addressed during Se creS of die 

thfough^l Se dSd.^ ' represents a comprehensive approach for implementing EC 

1.1 Objectives of EC and EDIin DOD 

The EC in Contracting PATs Chaner directed that certain actions be performed during the review 
EC SSn^c^Sfp\-T^ team's objectives.and were assigned to working groups within the 

EC m Contractmg PAT tself This allowed the working groups to focus on specific objectives durin^ 
rc.m^.rin"%Tr Al^°'.^"P"^,^^«t- solicited from both private and publi? entities based on tlTe EC 
m Contracting PATs objectives. All information compiled from research, site visits and resoonses to 

JvefeSwsr '''' '^"^ '^^'^'^ ^ ComSg PAT 
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* fn''fi^^\°^° capability to support competitive procurement and improved access and notice 
o sm^ busmesses m support of mcreasing the simplified acquisition tliresiiold 

. Identiiy any re evant EC policy issues related to near-term and long-term EC imDiementarion 

* VafS AS.^T^^^'^ ^^"^'^^ incIude'huS netwX^^ys 
^r^n^lff Networks (VANs . etc to support EC. Identify areas for s^dardiSdon f e7 

m^^?H^?i.'?T"''°'?' ^f^ certification, vendor registration, etc.). TheT^se offe'task is 
0 Identify likely fixmre developments for which options should be maktainedS^e °' ^ 
unplementationofcurrent and available capabUities and systems • '^^""^"^^ 
I nSSS" and assess potential areas of risk and uncertainty related to near-term EC 
2r^?P a comprehensive miplementation plan with specific tiLe-phased recomS?ndations The 
plan should Identify options, mcludmg estimates of resources requked to acSTa Sd 
expansion of EC m contracting within DOD. Additionally, initiatives to pubUcize aS iducate 
Government and Industry on EC contracting activities wodd be addressed 

* kS^" deployment of a system that would provide a "single face to 

1.2 Functional/Technical Assessment and Analysis Results 

'^.u^^^?°?f^k°^ ^9^?^ capabilities to exchange data related to the procurement process as tiiev exist 
withm the DOD and other federal agencies (e.g.. General Services AdLnistraS (GSA) Sm^^^ 

Spec "ofl^f c^^^^^ goD ^^rTnr'T,'--"^^ ^^^^^"^^-"^ ''^'^'^ Che S^Sechnical 
aspects ot the cuirent DOD EC/EDI capabilities m contracting ncludina, but not limited to Intearated 

Procurement System (ITIMP), Standard AutomS cTnScSigT/s^^m 
(bALONS-^0. SAiM^IS Procurement by Electronic Data Exchange fSPEDEI Government 
Acqmsmon Through Electronic Commerce (GATEC), Menu Assist! d D'ttlliiis^^ 

n^i^e^^e^aSTp^^^^^^^ ^ orde?;&2;^hfe?able 

witii unproved access, notice, and participation of smaU businesses. Lnti^rthe EC iTcon^a^^^^ 
nTn.^?' ??r2SP -^^^^.P^^^-^ (Navy. Army, Air Force, DLA, DISA D^AS^d DeS^pS 
r fen'^-^''^ ^^^^^ ^""^ automated small purchase procurement svsiems A strateak anal 

of DOD IS to present a "smgle face to industry." Therefore, the EC in ConSnaTATfocusS^ ^ 
methods to achieve a common standard in the distribution of EC/EDI actions to DOD's ncLers 
In addition, the EC m Contracting P.AT examined ways to assure that improved notice ofoendin^^ 
procurements could be provided to insure participation by small businesses ^ ^ 

In support of the findings of this EC in Contracting P.AT, a number of issues required a consensus 
approacn b>- all members. Witiiout these basic principles to establish the framevvori^ for fSS^e 

ru^oTr^exn^ll^^^^^ ""^^"^ ^^^^ ^^-^^ ^° sustaTn a fo^Ld DOD 

solution tor the expansion of ECEDI witii Industry m contracting. The following are several of the kev 
consensus items discussed that represent the baseline functional requirement for cSeSon i? Ae 
expansion ot EC in Contracting throughout DOD: consiaeraaon m me 

• DOD must present a "single face to industry." 

-niis issue was^clearly the most important to tiie EC in Contracting P.'\T. A "single face to industiy" is 
defined as periormance of EC by the Govermnem using EDI in accordance with federal Sf?Sn 
processing standards and a common set of business practices and operational pSlS l7m™t be a 
solution which al ows the vendor to be able to process tiie transaction to a^d^oS Inv DOD act^ 
minimally subscribe to one V.AN' to do business with all DOD, and register onlv on«To becom^^^^ 
suppiier (ratiier tiian witii each DOD component'activity). oecome a uuu 



2 of? 



n/13/96 8:1 



nap;./www.j!Sa..T. l '/onir.puos/straiegy/ac 



• A single point of entry will be provided by DOD. 

P5?J^ developing a repository for centirtii fegistnition of electronic addressing "information, trading 
parmer agreement infonnauon, tedmg partner profile, and other pertinent supplier information ife 

will not be restricted to procurement system access only. The contractor reeistration oroce« i«! ^tt^t^La 
to replace the Standard Form (SF) 129. Commercial AAd Governm^Sty SgE)^^^^^^^ 
and smular local forms mfomiation. A capabUity for use of EDI to couSd upS^this d^^^^^^^ 
™. i-S'l^^ will mclude.the ANSI X12 838 transaction set. as well as other LSo^S deeded 
This will provide a smgle pomt of entry to obtain access to all DOD requirements. neeaea. 

. DOD will use ANSI XI2/EDIFACT for administration, commerce, and transport. 

S.!!f n/?5"*''- o^POD conventions requires inter-service coordination and a central point of contact 
1^^^^^ fesponsible for configuration management, with Procurement CIM sponso^hi? Sd 
tidustry mvolvement Functional data decisions will be resolved by the appropriate Office of the 
Secretaiy of Defense (OSD) sponsor. In order to faciUtate the merger and avSdmd^t devd^^^^ 

Z^c^^^^^A ^A '"'^ ^^^J development of implementation conventions ?^eSt Ae 
appropnate standard mandated by the usmg community. 

• Architecmre will suppon all other DOD operational or functional requirements. 

bi5ne?s fi^cSS:'''''^'*'"" will recognize and accommodate the operational requirements of these 

1 . Procurement 

2. Contract Administration 

3. Transponation 

4. Supply Management 

5. Financiai.Management 

6. Maintenance 

7. Engineering 

■ . '\ 

• Use of commercial and Government products. 

TTie EG infrastrucrure will be based on approved technical standards that support DOD open svstems 
objectives that mclude ma.ximum use of Commercial-Otf-The-Shelf (COTS) and reusable 
Govemment-Otf-The-Sheif (GOTS) sotuvare products that have been tested. aSceS a^d are 
supportable by the Government. DOD will issue a supported list of COTS and GOTS oroducts A 
central repositor>' for reusable GOTS products will be identified. '"^ ^ ^ proaucts. A 

• Use of VANS. 

"^^^P ^^^P^ architecture will provide connectivity to public and private V.ANs to exchange 
Ev . • ^sactions with ttading parmers e.xtemal to DOD. This mcludes use of dedicated lines 
?e™f EbJ"^^^^ ^^^^ '"^^ bulletin-board services rather th^directed 

Io^rrl^ri!?F?Sn?if P?"?*'^^^:'^ °/ ^^^^ Industry has developed in the area of EC/EDI and what thev 
P ^T cn T ^« Government, it was recommended that the EC in Contracting ' 

PAT sohcit Industry input on their initiatives. A standard questionnaire was provided to kev IndSir^ 
associations representing over 9,500 companies in an attempt to reach the l4est possible auSe 

Based on the responses received from the VAN community, the V.^Ns will suoport anv DOD EC/EDI 
procurement initiative that is standards based and underpinned by a single set of pplid«^d procedures 
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2.0 Basic Requirements 

d«cription cfc^k of than and also idcntffi J'wU=?xi2''SSSSn's2s^ SSSt^™"^ " 



1 Procurement/ Acquisition Reform 


[Project ID | 
95DLA 005 | 


Project Title — | 
Commerciai And Government Entity Codes | 


(Procurement/ Acquisition Reform 


95NAV011 1 


Food Service Management | 


1 Procurement/ Acquisition Reform 


95NAV016I 


tDI Afloat j 



3.0 Analysis and Considerations 



Attachment 1 to Appendix A 
Procurement Projects Supported by the DOD Electronic Commerce Office 



PROJECT 95D LA 005 
Objective: COMMERCLAX GO VER.\MENT ENTITY (CAGE) 

^aWenTnf r"??? ^^^^^'^I^I ^^01 vviH provide greatly improved cum around times in the 
vIKllSnlJc's '^tllTj;^:. a^tti;^^^^^^^ disseminf ^j^^^^^ for . 
with the gove:Tiiiiem using ECEDL 'registration mechanism for vendors domg business 

Project: 

Defense Federal Acquisition Re2ulations Supplement, at DFARS ''046 reS^^^ ?p FSS. The 
procurement in excess of S25,000. PP'^meni, ai ur AKi _U4.6 require a CAGE code on any 

On December 20, 1993 the Electrom'c Commerce A.ciion Team (VCats Jcc.,-^ . _ . 

other things recommended a "single face"TgTvenSent forTe^d^^^^ "^^Ih 

government. Such business should be conducted using LcS'coi^^^^ 
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Interchange (EDI) conventions. Based upon this recommendation the Defense Logistics Service Center 
(DLSC) and Defense Automated Address Service Center (DAASC) joinUy developed and depioved a 
door to door" mechamsm for processing CAGE cbdes requests using 838 "Trading Parmer Profile" 
transaction sets. This mechanism became operational in June 95 by processing the Trading Partner 
Profile transactions for the Central Contractor Registration (CCR) system. 

The CAGE/EDI system has been funded for fiirdier automation under DOD's Office of Electronic 
Commerce which is under the Deputy Under Secretary of Defense for Acquisition Reform This 
expanded automation project wiU be accomplished in four phases, each of which is should'be 
accompushed m three months. 

The fuUy mechanized CAGE/EDI system will provide greatly improved him around times in the 
assignment of CAGE codes as well as a comprehensive on-line information dissemination system for 
vendor demographics. The CAGE/EDI provides a "seamless" registration mechanism for vendors doin^ 
busmess with the government usmg EC/EDI. * 

PSA; Acquisition Reform/Procurement 

Lead DOD EC/EDI PM: DLA, POC Terrence Hunt 

(616)961-4856 

Transaction Set: 838 Trading Parmer Profile 

Status: Deployment 

Deliverables: 

Match no Match Capability 

-Automated CAGE A Assignment 

Database E.xpansion 

E.xpanded Information Dissemination 



PROJECT 95NAV Oil 
FOOD SERVICE iVUxNAGEMENT .\UTO^UTION 

Food Ser/ice Management (FSM) is the only certified automated information svstem used in the Naw 
to suppon general mess (GM) financial and inventory management functions. FSM, developed more ' 
than a decade ago, bases all functions and operating decisions on a set of policv and procedures desit^ned 
to support paper-based operations. In shon. FSM automates manual records keepina functions ° 
hardware configuration management and support for FSM has not kept pace with FSM software 
development: as a result many of the 477 Navy general messes are operating on obsolete hardware under 
appro.ximateiy 4d different configurations. FSM is entirely stand-alone and does not share information. 

Subsistence Prime Vendor (PV), a DOD initiative to procure provisions direcriv fi-om commercial food 
distributors, provided the vehicle required to help move Navy food service into' a less paper-based 
fcnY-?N"^m^V^"^^^I"^^ "^^^^ through PV utilize the Subsistence Prime Vendor Interface 

(bP V I). SPVI, an Electronic Data Interchange (EDI) translator which accepts customer orders and 
receipt information and forwards them to Defense Personnel Suppon Center (DPSC) and to the vendor 
IS labor intensive and requires manual data entry. Procurement, receiving and bill pavment processes are 
metiicient and cumoersome using current SPVI metiiodoloav. DPSC is the information broker 
controlling flow of information to vendors, ordering activitfe's and bill paying activities. 

Naval Supply Systems Command (NAVSUP) has developed a notional concept of operations for food 
service operations which e.xploits advantages of new technologies and PV initiatives. Enablin<y 
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tecnno ogles such as bar-coding and EDI will allow Navy food service procedures to be significandv 
streamimed. In addition, data flow directly to the parties requiring it to perfonn their functions 
il?""^!^^^ ^^^^ information brokers are eiiniinated. American National Standards Institute (ANSI) 
X12 EDI transaction sets wiU be used in all phases of the procurement and bill payment. Information 

T:l m'^^ c^^^i*r?nc^°^^*"°§r,^°''^^•. ""^^'^ ''^ P^^^^S activities. Defense Finance Accounting 
bystem (DFAS) and DPSC. In an afloat environment, FSM will forward procurement data to the EDI 
translator via the shipboard network. Ashore, FSM will forward data via phone modem directly to a 
snore-based translator. ^ 

Under^the NA VSUP concept of operation, FSM users will be able to place orders, certift^ receipt of 
provisions and authorize payment of dealers hills using EDI transactions. Infoimation provided from the 
JlAr^"^"^^ as catalogs and shippmg notices will be forwarded using EDI and directly uploaded into 
FSM. These shippmg nouces will also provide Uniform Product Code (UPC) infomiation which will 
further enhance benefits denved through bar-coding. Bar-code information will be available to an 
ordering activity before any provisions are ever received. Time and labor requirements to perfonn 
provisions receipt and sto^^^ge ^yill be significantiy reduced while inventory validity incr^es. Vendor 
bills wUI be certified usmg EDI transactions and paid via electronic funds transfer. Eventually all 
u x';^^^cI;'?S^®°^^°^^" ^® replaced with EDI transactions. Fully implementing EDI as defined in 
the NAVSUP concept of operation will allow several non-value added functions and costs to be 
significantly reduced or entirely eliminated. EDI will fecilitate the efficient sharing of infoimation 
eliminate paper transactions, minimize manual data handling and associated errors and reduce non-value 
added processes. 

PSA: Acquisition Reform/Procurement 

Lead DOD EC/EDI PM: LCDR xVIorris Capian 
(703) 602-36B6 

Transaction Sets: 

821 Financial Reporting 860 Purchase Order Change 

824 .Application .Advice 86 1 Receiving .Accept 

832 Price Catalog 864 Text Message 

850 Purchase Order 865 Purchase Change 

857 Shipment Notice 997 Functional Acknowledgment 

Status: Prototype 

Hardware for shipboard upgrades of 1 90 ships. .Analysis & Systems Intesration 



PROJECT 95NAV 016 
EDI .AFLOAT 

The shipboard community uses multiple legacy supply and financial svstems to meet the reporting 
???b 1^1^*"? for accounting and inventory data required by the Defense Finance and Account Sen^ice 
(DFAS) and the Government .Accounting Office (GAO). Current afloat legacv systems are bein* 
replaced by a Relatioiial Database .Management System (RDSMS) and 4th Generation softwareTcalled 
R-SupplyX Additionally, currem legacy tmancial programs will be replaced bv DFAS interim mioratory 
systems. The afloat systems do not provide data real-time or in the detail required bv the mterim * 
migratory accounting systems. Discrepancies due to manual data entrv and the time-la<T caused bv 
numerous paper/tape transactions going back and forth between the ships and shore activities •'et 
compounded while at sea. A 45 day accounting cycle exist because of the time involved in receivinc^ 
00 igaiion and billing Information from afloat and ashore activities. To provide real-time input detail 
obligation and expenditure data, and allow for independent development of software: Electronic Data 
Iniercnange (EDI) is seen as a proven mechanism to which will allow these goals to be met. 

The Navy will use EDI for data exchange in developing its afloat software and migratoty accounting 
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Vr^T'Z^ l l ° •""^f'T ^° movement of financial data ashore bv reducing 

complexity and by providmg timely data, thereby reducing the accounting cvcle. Additionally EDI will 
provide for mcreased asset visibility, compressed telecommunication transm'issions, and allow the Naw 
to consolidate and standardize its business practices afloat and ashore. 

EDI coupled with R-Suppiy will also provide the Fleet with the ability, to take advantage of numerous 
Defense Logistic Agency (DLA) miuatives mvolving the use of EDI within the private sector Thesr 
minatives involve customer direct ordering of various commodities from vendore. Currently * 
pfaannaceuGcal, medical/surgical supplies and food items are ordered electronicaUy using interfaces In 
£ n^^Ti, "if of elecnromc catalogues provided via EDI, and resident in the afloat software would 
be used. TTius, aUowmg the customer to select the required Items and transmit an order via EDI for 
delivery to the afloat activity. ^^^^-^ji 

PSA: Procurement 

Lead DOD EC/EDI PM: Navy, POC CDR Doug Ballou 
(703)607-0835 * 

Transaction Sets: 

51 1 Requisition 855 Purchase Order Acknowledgment 
810 Invoice 856 Ship Notice 

821 Financial Reporting 857 Shipment and Billing Notice 
846 Inventory Inquiry 858 Shipment Information 
850 Purchase Order 888 Item Maintenance 

854 Shipment Delivery Discrepancy 940 Warehouse Shipment Notice 
Information 997 Functional Acknowledgment 

Status: Prototype 

Develop Prototype, Analysis and Evaluation of Proof of Concept and Expanded Prototype 
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APPE>a)IX B - DOD FINANCE AND ACCOUNTING 

(POCOUSD(C)) 



1.0 Background 



The Deputy Secretaiy of Defense directed the establishment of a working group to deveioo a course nf 
action to alleviate Je systemic problem of Umnatched Disbursements mDs). Und« the^^Se of 
&e Acquisition and Fmancid Management Panel, co-chaired by the DOD ComptxouS^d^e PrincSJal 
Deputy Under Secretary of Defense (Acquisition and Technoloiy), the AcquisitiSi aS pSanciaT ^ 
Management Workmg Group was chartered for that purpose. M ukmatched disbiJs^enU?Sy 
disbursement received by an accountmg office that cannot be accurately matched to the correct 

rniSf ^ ^^P^^^'^ billion in iLnatch5<^L*4emSL 

Contract payments made up the majonty of the dollar value of unmatched disbursements. 

The report, Eliminating Unmatched Disbursements - A Combined Approach, prepared by the 
Acquisition and Fmancial Management Working group, presents 48 recommendations focusing 
pnmanly on short and mid-tenn unprovements. Within the recommendations a central theme to make 

o?loXlSS°a^^?S1^i'^°^^^^ 

npfq^n ^""iP '^P""^ ^^'^ ^^yses to refine the recommendations. 

DFAS and DOD now have undemay a program to implement the final recommendations of the 
1?^^^ P'"""^ ^^^^ already completed many of these actions. The technical implementation of EDI 
wSis'mSnedt^^^^^^^^ ' ^''^^ ^^'^"^ Information. In4tnicmre (EHI) ^ 

J?ch.?!-^^"'^ ^i""^" ^'^ Accounting Service (DF.AS) is responsible for providing financial, accounting 
disbursmg, and reporting services to the various Department of Defense aaencies Ind other 
gov-enimental entities. DFAS operates financial applications at 2 1 operatirig locations that report to five 
DFAS centers- which report to DFAS Headquarters in Washington, DC. 

l^caSlnm lo^^^^^ accounting functions, each center performs specialty functions that vary from 

The following is a list of those specialty functions: 

• DBOF Accounting and Payments 

• Support Services 

• Security Assistance 

• Customer Service and Performance Management 

• General Counsel (and Garnishment Operations) 

• Financial Operation Review and Perforaiance Assessment 

• Contract and Vendor Entitlement 

• Military- and Civilian Pay 

• Travel'Pay 

• NAF Accounting 

• General Accounting 

• Transponation " . ' 

Each operating location is supponed by a Defense Megacenter (DMC) as shown in Exhibit A.l. 

As a^core business function Finance and Accounting has required extensive sharing of data and 
venrication of accuracy of data. Various forms of data sharing have been developed includin- paper 
9«trac.< tape proprietary data formats over Defense and private net^vorks (Defense Data Net^^ork ' 
Autcmiatic Digital Network, etc.). File Transfer Protocol and Electronic Commerce/ErectrS okta 
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DFAS ARCHITECTURE 
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Exhibii B.l - DFAS Architecture 
In addition to exchanging infomation with other DFAS svstems and DOD a-^encie. DFa c 

cross-toctional integriion disciBsio KratS?^ tlSt " u 

accounts receivable depanmeat, and U>e DFAS's acTouSc payabk diZSS. "^'^ ^^"^ ' 
2.0 Basic Requirements 

pe'rcem "lV3"b^n,S1 a^bS i'»>'ur3em«.ts. Approximately 

conditions, as well ^^1 Xl^SI? "for m%d 

Translation Service (X12 3050 850 and 860) for the Army. Navy, Air Force and DLA 
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• Compliance Testing of all Service and Agency generated transactions 

• Audit of transaction through the infrastructure 

• Two hour delivery service for all 850 and 860 traffic 

The next phase in solving unmatched disbursements is to implement EDI for pre-payment audit of 
vendor mvoices. Vendors normally submit their invoices directly to the DFAS center responsible for 
f^^^^'^J^^^r^^' ^^^^'^ accounting system may not be updated to reflect any contract modifications 
In the past, if the accountmg system determmed there was a discrepancy, a DFAS payment officer wodd 
attempt to reconcile the differences over the telephone with the AGO and/or the PCO DiSne^s Zse 
die contact wntmg systems will provide all contract information to the accounting system uiine an XI 2 
850 or 860 transaction set This will, enable DFAS' accounting system and the ACoS TcoS^es 
to remam synchromzed. The requirements for this phase are: lu rv.^ oaiaoases 

• Translation Services (X12 3050 810) from the AGO / PGO to the DFAS Genters 

• One-to-many transaction routing 

• Network Entry Point Services for vendors to submit invoices (X12 3050 810) 

iVnn^P ^""^ ^"^g phase, DFAS will pay the vendor 

u^ A ^^ Remittance Advice to the Department of the Treasury to ensure the cbrrect account 
is debited. This same payment mformation will be supplied to the AGO and PCO. This testing is 
scheduled to commence in April 1996. The requirements for this phase are: . 

• Translation Services (X12 3050 810 and 820) 

• Electronic Funds Transfer (EFT) Services 

• One-to-many transaction routing 

SSe^f^fcu ^°.^P^7«nt *is EDI capability to all DOD procurement, contracting, and accounting 
systems It will also jnclude exchange of EDI transactions with the Department of Treasury, and anv 
odier federal agency with whom DOD conducts business. Requirements are still being identified for this 

S?<?nr A^f^^'r'nnT? • P'^j'" ''^^^LSj^ded, at least partially, and supported by . 

DUSp(AR/EC), the DOD Electtomc Commerce Office. Attachmem 1 to this append^ contains a short 
descnption of it and also identifies which X12 transaction sets are being used 



PSA 


Project ID 


Project Title 


Finance 


95DLA014 


Electronic Funds Transfer 



3.1 Analysis and Considerations 



The main issue impacting implementation is the ability of DOD applications to accommodate DFAS 
S h'^'Z!".^^- 1°"^^ apphcanons, such as the Army's SAACONS, have indicated that much work needs 
to be done to change their legacy systems to provide application User Defined Format (UDF) files for 
860s and to comply with XI2 version 3050 of any traiisaction set ^ 

DFAS has a requirement to address and deliver single transactions to multiple locations. Current XP 

?r^.1Stln^ ^nnrV^ ''"^i^ i^^'"'" ™s restriction results in the Service or Agency 

u-ansmimng a UDF for each addressee, which consumes scarce resources and increases the costs of 
doing EDI for the ftinctional area. DISA is working to resolve this issue and has determined there are 
^Tt^i i'Pi'^''^ available. Some opuons are sponsoring a request for change to the X12 standard to allow 
multiple addressees or to build this capability into the Electronic Commerce Processing Node. 

Multiple organizations are setting EDI policy. This conflicting guidance causes confusion for 
SemcesMgencies while they are developing requirements and application specifications for EDI 
projects.To eliminate this conflict m policies, the procurement and financial policy offices are 
coordinating data requirements among themselves. The Acquisition and Financial Management Working 
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Group (AFMWG) has been established to accomplish numerous actions to resolve unmatched 
disbursements. Many of these actions mvolve EDI implementations. 



Attachment 1 to Appendix B 
Finance Projects Supported by the DOD Electronic Commerce Office 



PROJECT 95DLA 014 
SUBSISTENCE ELECTRONIC FUNDS TRANSFER 

Objective: 

This initiative will provide the Electronic Data Interchange (EDI) transaction for the Federal Reserve 
SL^^" r^d^Jhe c^^^ back to the vendo'rs bank'as well as a r^i^celSJice S^^^ 

the vendor. Fmally, it will provide an overall audit trail of the financial transactions. 

Project: 

^vf ^'^^''^ Accounting Service (DP AS) currently pays subsistence invoices using a mailed oaner 
check, llie annual pnce to accomplish this process is over $6 Million ($65 per invSor^O 000^ 

nf/?- ^5 '"^"^ P"'""'' determination by the voucher Examiner 5iS the 

should be paid and is not completed until the check reaches the vendor via the mails. 

This project will work for the payment of all subsistence vendors. It is an enterprise project and deals 

rrn Disbursement (CCD) Transaction with an 80 character addendum record 

The CCD IS a Treasury transaction that works through the automated clearing house of the Feder J 
Reserve Banks. First, it will provide the Electronic Data Interchange (EDI) tLsaction for thrFederal 
Reserve. Second, it wi 1 provide the cash disbursemem back to the vendors baSk i wel liTrei^^^ 
^ice transaction back to the vendor. Finally, it will provide an overall audit trail of ^efinS 



Because the timely processing of this data is critical (7 day payment of billing) and the importance of 
sTf.2nl? P^"^ " was determmed that it was in the best imerest of the Defeise LoeytSrAg^ncvs 
rnrllfl? ^^'°f?T ^'^^^P P^°«^sing within Defense Integrated Subsistence ManagemenrSystem 
(DISMS) Th£ funding for this project (SI84,000) will cover the programming which wiU be^ 

n^Tx^c' f ' Systems Design Center. This progiSmlSireqSrerAe m^^^^ of 
Z^^ZZ?J!^^^ r Seven of these modules are in the contracting^area while die remSng 

three modules are related to financial processing and payment. i^xiimmn^ 

This project in conjunction with the Electronic Invoice Project will reduce the amount of manual 

Thi'i'nh '™ ''T'^ ^"^^ ^'^^""y ^^"^'"^^^ P^y"^«"t to subsistence vendor SSnicallv 
The enhancemen to an electronic paymem process is seen as the incentive to the small buskess venrrs 
to convert to an electronic invoicing system. Our initial analysis has shown that procSsLaTinW 
for paymem electromcally should reduce workload for DFAS and evend^ly cos^t^^^ToS^T^^^^^^^ 
program. The estimates of what an electronic mvoice costs to process are $10 (down £ Ae 

manual process). Using these estimates, when Electronic Fun£ Transfer and the eScg^Sc LScW 
Miliion ^ implemented our cost savings on a yearly basis are estimSed to excSs^ 



Million. 
PSA Finance 

Lead DoD EC/EDI PM: DLA, POC Jeffrey Nienstedt 
(215)737-3860 

Transaction Sets 

820 Payment Order/Remittance .Advice 823 Lockbox 
850 Purchase Order 
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Status Prototyping 
Deliverables: Software 
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APPENDIX C - DODTRAiNSPORTATION - 

(POC USTRANSCOM TCJ4-LT) 



1.0 Background 

5 n??c\???^.^'^^^" Assistant Deputy Under Secretary of Defense - Transportation Policy, 
ADUSD(TP), conceived the Defense Transportation EDI (DTEDI) program, the Defense transportation 
community has stiiiggled to sustam mitial development efforts. Often using minimal resources it has 
had some success m unplementmg EDI capability in three areas - transportation rates, government bills 
of lading (GBLs), and earner mvoices. As a means of more efficiently advancing those efforts the 
Defense transportation community established the DTEDI committee to guide it through the iilitial areas 
of EDI development mto a long-term EDI fielding and maintenance effort. 

Jrr???' ^^i^^Jj^"" Management Command (MTMC) fielded its CONUS Freight Management 
(Lf-JV^ system. The CFM system receives electronically formatted standard tenders containing freight 
rates from commercial carriers. Defense shipping activities access CFMs rate file to assist in mode 
selection and determmmg the cost of a shipment prior to a move. MTMC has now qualified more than 
lUU commercial earners for submittmg standard tenders elecfronically to the CFM. 

Complementing MTMCs CFM are the Services and DLAs electronic GEL project and the DFAS-IN 
Defense Transportation Payment System (DTRS) which is developed to receive and process costed 
GBLs and earner invoices electronically. DFAS-IN has made its EDI capability known to the carrier 
industry and sought to expand its use between DTRS and earner systems. DFAS-IN implemented its 
electronic invoice capabHty m 1994 and cunently has the capability to receive elecfromc invoices from 
more than jO commercial earners. 

In a May 1 994 memorandum to the Secretaries of the Military Departments and Directors of Defense 
agencies the Deputy Secretary of Defense - Logistics, directed all DOD Components to make maximum 
use ot EDI m all business related transactions. As a result the Defense transportation community is 
exchanging'bills of ladmg, mvoices, rate tenders, and shipment status messages electronically amon<y its 
members and commercial mdustry. Completing the implementation of EDI into those processes and* 
accelerating its expansion to new areas has now become a primary objective of the Defense 
transponation community. 

Hnl"J oT?' ^^^J^^^ Under Secretary of Defense - Logistics, designated the 

r^^^ n?^^M^r?^Tf^^ °" Command (USTRANSCOM) as lead agent for the DTEDI progrlm. As a 
result, USTRANSCOM developed a plan that presented a strategy for managing the prograi^ That 
strategy calls for USTR.ANSCOM to develop a comprehensive implementatk^n'planLtl^ers ft«her ' 
development and expansion of the DTEDI program. Since that time, USTRANSCOM has undertaken a 
senes of actions that will enable the Defense transportation community to improve its program 
management capabilities, continue e.xpanding its EDI efforts, and accelerate the development of new 
initiatives. The Defense Transponation Electronic Data Interchange Program Implementation Plan 

^^^^^PK^SPp^s^ ag^essive program to accelerate the pace of EDI implementation in support of 
transportation. This plan is aimed at focusing energy, attention and resources toward expanding EDI 
uses m suppon of pOD transportation business infonnation exchanges. It identifies basic requirements 
for the use of EDI in support of DOD transportation in addition to detailing the current EDI initiatives It 
turther describes in some detail those actions regarding the freight transportation program and proposed 
plans and schedules tor implementmg them. The current plan onlv addresses implementing EDI in the 
ProSii^^To '^^^ transportation system and the eleven processes that support it. Durin«T FY96 
USTRANSCOM will describe DODs EDI programs for passenger and personal property transportation. 

Along %vith its successes, the Defense o^sportation community has gained valuable experience during 
the development and fieldmg of these EDI initiatives. The DTEDI committee has been particularly 
mstnimental in resolving problems. Some of the DOD Transponation EDI initiatives have matured past 
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the development phase and are entering the life-cycle phase. The DTEDI committee, with its established 
adniimstrative and technical procedures, provides a strong basis for addressing the issues associated with 
the life-cycle maintenance process. 

2.0 Basic Requirements 

Y^?vS^T^F^"®"?^ ^^^^^ developing EDI processes and managing their coordination through 
me DTEDI committee, the Defense transportation conmiunity has laid the groundwork for expanding 
EDI applications to all facets of transportation and adapting rapidly changing business and technological 
environments. . 

The DOD is seeking to enhance several transportation and logistics processes using EDI. Specifically 
the Defense transportation community is exchanging bills of lading, invoices, rate tenders, and shipment 
status messages electromcally among its members and commercial industry. Introducing EDI technology 
into those processes directly benefits several DOD logistics programs such as the Total Asset Visibility 
(TAV) and InTransit Visibility (ITV) integration programs. Completing the implementation of EDI into 
those processes and accelerating its expansion to new areas has now become a primary objective of the 
Defense transportation community. 

The Defense transportation community has implemented the EDI GBL Billing and Payment and Carrier 
Rate Submission Projects using Sprints EDI VAN services procured under a GSA contract Those 
services are now being provided by Sprint under provisions of a Federal Telecommunication Service 
2000 contract. USTRANSCOM is evaluating four communications alternatives to provide its long-term 
and interim EDI telecommunications requirements. The DTEDI program requires an EDI VAN for DOD 
activities to exchange data electronically with their commercial trading partners and with their DOD 
trading partners that do not have access to a military data network (such as DISK). Transportation 
activities should continue to use DISN when it is available for exchanging EDI data within DOD but 
they also require access to a commercial EDI VAN. That VAN must have the capacity to satisfy Defense 
transportation s value-added telecommunications service requirements and its estimated volume of data 
(A list of value-added telecommunications services is described in Chapter 6 of Defense Transportation 
Electronic Data Interchange Program Implementation Plan). The four telecommunications alternatives 
under consideration by the DTEDI are: 

1 . Use the Federal Acquisition Computer Network (FACNET). 

2. Use the EDI VAN services available under the Federal Telecommunication Services (FTS) ^000 
contract. 

3 . Allow each transportation activity or Military Service and Defense agencv to contract separatelv for 
EDI VAN services. ' 

4. Use the EDI VAN service capabilities of the GTN contractor. 

The alternative that best satisfies the Defense transportation communitys requirements has not been 
selected. The DTEDI needs to select the least-risk EDI telecommunications alternative. Defense 
transportation s bill of lading electronic payment program currently operates in a production 
environment so it cannot implement an EDI telecommunications strategy that is unproven. The DTEDI 
program needs to embrace both an interim and long-term strategy that offers the lowest risk to its current 
EDI initiatives. 

3.0 Analysis and Considerations 

Analysis: The Defense Transportation Community with USTRANSCOM at the lead has determined that 
EDI will be used as a vehicle for transportation modernization. 

Considerations: EDI Implementation Conventions must be developed and maintained to meet the 
business requirements of all trading parties to the exchange. Business processes, rules, and practices 
must be understood with Automated Information Systems synchronized to version and release in a 
thoroughly integrated strucmre to gain real advantage fi-om the EDI technology. Ad Hoc development 
efforts usually prove of hnle value and lead to more fiiistration and cost to update than do corporate 
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actions. Configuration management of software and implementation conventions is o£utmost 
importance to mpid and effective utilization of EDI when meeting daily business needs. 



Attachment 1 to Appendix C 

Transportation Projects Supported by the DOD Electronic Commerce Office 

The following Transportation EC and EDI project is being funded, at least partially, and supported by 
DUSp(AR/EC), the DOD Electronic Commerce Office. Attachment 1 to this appendix contains a short 
description of it and also identifies which XI 2 transaction sets are being used. 



PSA 


Project ID 


Project Title 


Transportation 


95DLA017 


ASN Consist Initiative 



This project description was not on the diskette. 
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APPENDIX D - bOD MEDICAL LOGISTICS . 



1.0 Background 



Medical logistics is a fiinction wiAin the Militaiy Health Services System (MHSS), a worldwide 

°f ^^..l^^^th resources of DpD, Army. Navy, and Air Force. The Station 
required for MHSS covers a diverse range of peacetime and war-related areas including coordSated and 
managed care, preventive medicme, research, and logistics. Medical logistics suppom the S he^ 
care delivery mission by furnishing materiel, equipment facilities, services and iSomation^ources 

• f/'i^, T^""®^"^^ ^''^.P^?^^"^^ ^'P^'^^^^s Army, 19 Navy and four Air Force 
lkt"offiS'4^^^^^^^ 

. Air ^.f^^--^<^J:'0&sdcs (MEDLOG) operates at 89 Air Force peacetime and contingency 
hospitals. MEDLOG provides comprehensive and integrated Medical Retail Supply support 
extensive quality assurance, assemblage management capabilities, medical equipment ' 
?f rS? Biomedical Maintenance capability. MEDLOG also support the administration 

nS'}^^ Agreements contracts. Mobile MEDLOG operates vSith Air Transportable 
Hospitals (29) to support wanme/conUngen medical supply. Mobile MEDLOG provides the 
same capability as MEDLOG but operates on a laptop personal computer. P^^^o^s me 

• f^S^c^^^^^X^^'^''^''^ Management Information System-Medical Logistics 

w)^?-^^^°°^°P^'?^"^.^'^^P®^^^^^"^« hospitals and 140 manaae 
^^w^^""'" TPS'"! medical supplies for contingency and peacetime recJiireS. ' 
TA^I^aS provides the Arniy with a single medical supply system supporting peacetime and • 
wartime/contingency at all active Army, Reserve, and National Guard medicll^s^ply o^^^^^^ 

• Army Medical Department Property Accounting System (AMEDDPAS) operates at 48 peacetime 
hospim^s and provides comprehensive equipment management including plannine, funds trackina 
property accounting, equipment maintenance, central asset visibility and excess rIdisSbuSn 

• Navy: Medical Inventory Control System (\flCS) operates at 17 Naw hospitals to provide an 
bTtSw SrF'iS^^^ accounting system for medical treatment facilities supported 

• Micro Medical Inventory Control System (Micro-^^CS) operates at 35 Naw medical and dental 
nr^^VfJlf --^aCS is the logistics system for'hospital ships and fleet hos^^^^^^^^ 
provide joint service interoperability support during wartime and in contingency operations. 

. Biomedical and Facilities System (BIOFACS), a commercial off-the-shelf system, operates at 55 
Navy medical and dental treatment facilities to provide support for property accoiiSlSd 
equipment management. f f j uuuuiigaim 

• Property Management and Budgeting System (PMBS) operates at over 80 Naw medical and 
dental treatment facilities to provide automate support for property management and accounting. 

• rlquiSment^*''"'^"'^"' ^'"'^"^ ^''^^^ " ^^"^ '° '"PP°" '"^^ P"^^^^« 

i^^^lPr^lmfL^in'liS' '^^^^ ^"PP°" responsible for defining and 

imp ementing an efficient medical logistics support enviromnent for health care operations in peacetime 
military operations other than war, and wartime. The program is composed of t^vo^m^^r?omponS^ 
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The program objectives identified for die MLFPIP and DMLSS AIS are: 

• nnnlbT^Tx ^^"^ systems to automate ail healdi care loeistics functions in 
DOD Medical Treatment Facilities (MTFs) worldwide. logisucs mnctions m 

• finH^-S • ^^^^ °^ " '^^ ^^FPIP and DMLSS environments bv 
XZl^l^:;^ty7^l ^-^^ ^^--^ MT^^SoSU the 

^SS!^^^ ^-P^-^ -entory. ensuring accurate 

• Improve accuracy and response time for Medical Logistics. 

• Incorporate electironic commerce technology. 

• Move toward a paperless transaction work environment. 

• Develop more efficient contract/payment procedures. 

Syste^ Sys,en, Decision P%er MilesioTlI^^'^^a, & S5''LTS^SrK{ 
2.0 Basic Requirements 

* that Medical Logistics wants to implement tiie prime vendor concent which utilire. 

direct connecuons to vendors outside of die DOD EC and EDI InWictl^ 

may be a medical =en«r. hospiul. Cinic (no m.;SS!^^JS^>,rto"pS g^T/aSir^" 
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i^"^iiuiHuui,siraicsy/app_u.nim. , http:,/\v\vw.aisa.niii/D7/oninpubs/strategy/app 

unit, or independent unit (e.g.. Naval Dental Centers [NDCs]). DLA DPSC is a DOD wholesale 
management function at a fixed location (Philadelphia, PA). 

The second environment is field medidal dpetatibhs. Traditionally, this environment is considered field 
operations in which mobile medical units have been deployed to a location away fi-om the fixed MTF 
and must provide the same level of logistics support. Field operations shall require DMLSS AIS 
equipment to operate effectively in a variety of environmental conditions. 

3.0 Analysis and Considerations 

The Preliminary Functional Economic Analysis for medical logistics identified deficiencies in decision 
support, commumcation, and information processing at all levels of the Military Health Services System 
m 1 992. The existing information systems relied upon a combination of manual and automated 
procedures for the compilation and transmittal of information. Information processing procedures differ 
between the three services and among information systems within each service. Each service ooerates 
and maintains its own hospital logistics system(s). 

The Medical Logistics Functional Process Improvement Program (MLFPIP) identified alternatives and a 
strategy to identify and implement unprovements that significantly reduce costs and improve medical 
logistics support. The Medical Logistics FEA examined three alternatives and chose the option with the 
highest return on investment The alternative chosen included the following options: 

• DPSC award centralized prime vendor contracts with commercial medical distributors 

• DPSC avvard centralized contracts with all manufactures of medical supplies for their entire 
product lines. These items would be distributed by prime vendor distributors direct to the hospital 
level. *^ 

• EDI will be used to order items, process invoices and provide electronic funds transfer 

• Items stocked at DLA depots will be reduced to levels necessary for wartime/contingencv 
responses » - 

• MLFPIP and DMLSS will be deployed to the largest MTFs first to achieve earliest payback 

• DPSC will be able to perform leverage buying of medical supplies to achieve the best prices based 
on consumption history 

3.1 DMLSS 

An integrated Defense Medical Logistics Standard Support (DMLSS) Automated Information System 
kr^^c^^ ^^^^^^'^'^ ^ ^ method to standardize business practices for all MHSS logistics organizations 
DMLSS .AIS, after implementation, will replace forms; perform on-line product research; report 
real-time stams of orders and fund balances: and serve as a crucial communication link between medical 
logistics personnel and customers, vendors, finance, contracting, procurement, maintenance support 
activities and other agencies. The DMLSS AIS development will be integrated with Business Process 
Reengineering initiatives that include bar code technology, contracting warrants, dedicated trucks 
Forward Customer support (FCS), inventory management to point of consumption, mechanized material 
handling systems. Medical Express, Prime Vendor, and TotalPackage Fielding (TPF). 

planned for deployment to nearly 350 large, medium and small medical treatment facilities 
(MTFs), .Army MEDLOG battalions, field units. Navy hospital ships, Air Force air transportable 
hospital, and Navy dental clinics. 

The DMLSS AIS is anticipated to: 

• Reduce pipeline time from when the need is identified to need satisfied 

• Reduce on- hand inventories 

• Reduce utility and maintenance costs 

• Reduce number of items destroyed because the credit or replacement reUim date has expired 

• Improve reutilization of excess serviceable items in the MTF 

-•• Reduce AIS and non-AIS consumables through use of electronic forms, reports, and documents 

• Reduce or eliminate late vendor payments through automation 
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DMLSS will be based on four subsystems that will support its users: 



L Facility management 

2. Equipment and technology man^ement 

3. Materiel management 

4. Customer support 

Medical logistics is linking the shutdown of legacy systems to both availability of the DMLSS AIS 
software and achievement of MAISRC milestones. The final mcrement of DMLSS AIS is scheduled to 
be available by 1998. 

3.2 EDI and Just-in-Time (JIT) 

EDI is planned to provide savings in administration and provide JIT implementation of inventory 
management. JIT inventory management can provide savings fi-om reduced inventories and associated 
costs, increased flexibility to allow relatively quick changes in medical emphasis and fostering 
competitive commercial practices to use depot operations when advantageous. The DMLSS EDI is also 
planned to allow MTFs to interact with the conunercial medical market and facilitate the use of local and 
decentralized Blanket Purchase Agreements. 

One item of concern to Medical Logistics is that it requires 24-hour receipt acknowledgment of 
transactions sentThey require vendors to receive Medical Logistic transactions within 24-hours. 
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APPENDIX E - DOD PROCUREMENT 



1.0 Background 

The military departments, defense agencies, and their components have developed processes and 
business practices, including approximately 76 unique Automated Information Systems (AISs), to 
perform their procurement missions. One AIS, MOCAS, also supports the financial commtmity's 
payments function. 

Although the processes and business practices at non-automated procurement activities operate within 
the same general franiework, they are not standardized. As a result, information transfer among 
contracting activities is often a manual process requiring multiple re-keying of data that increases the 
probability of errors and accurate DoD corporate procurement information is not readily accessible. 
Generally, such manual processes are labor intensive, costly, and less efficient than automated processes. 

2.0 Basic Requirements 

The Director, Defense Procurement, recognizing the ineiBBciencies and costs associated with sxistaining 
existing automated and non-automated procurement systems, established the Standard Procurement 
System (SPS) Program. The SPS is an iterative program with capabilities and deployment time phased 
to correspond with user needs and budgets. For EC/EDI purposes, the key elements of the SPS are: 

• a commercial software application that will perform standardized procurement functions, 

• standard procurement data developed in conjunction with DoD Enterprise data standardization 
effort, 

• a shared data warehouse that will permit receipt and distribution of standardized procurement data, 

• and the DoD Defense Information Infi:astructure(DII). 

System acquisition, deployment, and support are managed by the Defense Logistics Agency's Defense 
Procurement GIM Systems Center (DPCSC). 

2.1 Standard Procurement System Objective 

The SPS*s primary objective is improved procurement support for the Warfighter. To achieve that 
objective, the SPS application software will be deployed to each contracting activitv and access provided 
to the shared data warehouse and the DII. The linking of standard software, standard data, the shared 
data warehouse and the DII will provide each contracting activity with an improved, standardized 
EC/EDI capability, facilitate the procurement process and thereby improve end user support. 

2.2 DOD Procurement Electronic Data Interchange (EDI) Vision 

The Director of Defense Procurement envisions an EDI capability for SPS that allows a complete 
exchange of procurement information with DoD contractors, among DoD's procurement activities, and 
across DoD functional areas, in a paperless environment. To accomplish that vision, the SPS application 
software is required to receive or generate information in ANSI X-12 format, populate the DoD 
procurement data base mapping to DoD standard data definitions, and operate witiiin the DII 
communication parameters. Consequently, SPS will operate in any EC/EDI environment that is 
consistent with the DoD established criteria. 

3.0 Analysis and Considerations 

The following paragraphs describe specific issues related to EDI standards and legacy svstems related to 
the SPS program and a short summary of other projects that are underway in the DOD Procurement 
community. 

3.1 EDI Standards 
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SPS will use the national EDI standard, ANSI ASC XI 2, for its initial capabilities. Support for the 
UN/EDIFACT international standard will be added when that standard has been updated to include the 
required functionality for DOD procurement activity. 

Initial X12 transaction set support will occur at Version 3050, using Federal implementation 
conventions (ICs). Federal ICs will be produced for X12 Versions 3060 and 3070 which will be 
incorporated into SPS as necessary to support DOD procurement activities and trading partners. 

Initial UN/EDIFACT support is not expected until Spring 1998 with the release of UN/EDIFACT 
Version D.98A. Pilot programs with limited objectives may be executed earlier to gain experience with 
tiie UN/EDIFACT syntax. 

3.1.1 X12 Transaction Sets 

Initially, the SPS application software will generate or receive the following ANSI ASC X12 transaction 
sets and will interface with transaction set 838, Trading Partner Profile: 

824 - Application Advice 
836 - Procurement Notices 
840 - Request for Quotation 
843 - Response to Request for Quotation 
850 - Purchase Order 
855 - Purchase Order Acknowledgment 
860 - Purchase Order Change Request -Buyer Initiated 

864 - Text Message 

865 - Purchase Order Change Acknowledgment/Request -Seller Initiated 
Other X12 transaction sets being considered for SPS include: 

• 503 - Pricing History 

• 848 - Material Safety Data Sheet 

• 869 - Order Status Inquiry 

• 870 - Order Status Report 

Until its functions are incorporated into SPS, the Pricing Workbench will provide support for: 

• 25 1 - Pricing Support 

• 805 - Contract Pricing Proposal 

3.1.2 UN/EDIFACT 

The DPCSC is participating with the ASC X12 Purchasing Subcommittee, the Pan American EDIFACT 
Board, and the UN/EDIFACT Joint Rapporteurs' Team to accomplish mig^tion of functionality from 
XI 2 to UN/EDIFACT. The UN/EDIFACT messages expected to be initially generated or received by 
SPS are: 

• REQOTE- Request for Quote 

• QUOTES -Quote 

• ORDERS - Purchase Order 

• ORDRSP - Purchase Order Response 

• ORDCHG - Purchase Order Change Request 

• PRIHIS - Price History 

• OSTENQ - Order Status Enquirv 

• OSTRPT - Order Status Repon ' 

- SAFHAZ - Safety and Hazard Data 
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APERAK - Application Error and Acknowledgment 
3.2 Legacy Systems 

The functions performed by some legacy automated systems must be sustained until a fully functional 
SPS is deployed. The FY 95 and FY 96 reports required by Section 381 of the National Defense 
Authorization Act for Fiscal Year 1995 have been submitted to the Congress. 

Many procurement AISs presently possess an EDI capability using older versions of the X12 standard or 
using propnetary standards. DPCSC has supported several projects to convert legacy system capabilities 
to the Federal 3050 IC, attaining a "single face to industry" across multiple applications. Upon 
completion, each of these AISs will transmit and receive data via EDI with the same appearance as SPS 
This "single face" will allow replacement of legacy systems by SPS without disruption of EDI activity 
with DOD's trading parmers. 

Legacy systems converting to the Federal 3050 IC from earlier Federal IC's are: 



APADE 
DPACS 
ITIMP 

DPCSC is also providing an initial EDI capability using the Federal 3050 IC to a number of procurement 
AISs. This effort supports the DoD Comptroller's interests m obtjuning standardized, electronically 
transmitted, payment mformation for major weapon systems contracts. These include: 

AMAS 

Aivns 

PADDS 
MOCAS 

3.3 Other Procurement Projects 

Other DOD Procurement EC and EDI projects are being funded, at least partially, and supported by 
DUSp(AR/EC), the DOD Electronic Commerce Office. Attachment 1 to this appendix contains a short 
description of each of them and also identifies which X 1 2 transaction sets are being used. 



PSA 


Project ID 


Project Title 


Procurement 


95AFXXX 


Bar Coding 


Procurement 


95 ARM 001 


Acquisition Support Program 


Procurement 


95DCA 001 


Electronic Pricing 


Procurement 


95DCO 001 


EC/EDI Within DECCO 


Procurement 


95DLA 009 


Subsistence Multi-Line Invoicing 


Procurement 


95UMC 005 


Blount Island EDI 


Procurement/ Acquisition 


95NAV 002 


Contractor Performance Reporting 


Procurement/ Contract Management 


95DLA 001 


Progress Payment Request 


Procurement/ Contract Management 


95DLA 003 


Plant Clearance 


Procurement/ Contract Management 


95NAV 006 


Contractor Cost Data Reponing 



Attachment 1 to Appendix £ 
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Procurement Projects Supported by the DOD Electronic Commerce Office 



PROJECT 95AFXXX 
SUPPLY CHAIN MANAGEMENT & BAR CODE INTEGRATION 
BUSINESS PROCESS RE-ENGINEERING EC/EDI 

The existing process to order, track, and to pay for communication and computer equipment within the 
Air Force requires the use of numerous paper forms and other documents. The process starts with a user 
requesting systems that will enable the user to perform their job better through a C4 Systems 
Requirement Document (CSRD). The request is reviewed and, if approved by the AF Communication 
Squadron, turns into a request for purchase (AF Form 9). Once approved, the paper Form 9 travels 
through different offices for approval, review, and signatures with it ending up at Defense Finance and 
Accounting Service (DFAS) for commitment of funds. DFAS sends the paper Form 9 to the base 
procurement office to be manually entered into the base contracting accounting system (BCAS). The 
Procurement Office sends out a paper purchase order to the selected vendor. Paper copies of the 
purchase order are also sent to requesting organizations and to DFAS for obligation of funds. The 
vendor delivers the order to the Base Warehouse which, in turn, must notify the Communication 
Squadron and the requesting organizations through paper documents. Once the receivmg organization 
accepts the equipment, the Communication Squadron sends DFAS paper documents for vendor payment 
and expenditure of funds. 

The current paper system for ordering and tracking the procurement of communication and computer 
equipment is prone to errors, lost paper work, and re-keying of data into various proprietary systems. 
This scenario restricts the ability of organizations, in a timely manner, from tracking, payment, and 
accountmg of equipment. By using Activity Based Costing it was found that a typical AF Form 9 cost 
over $2,000 to process. In addition, reviews of Prompt Payment documents found that hundreds of 
thousands of dollars were spent on interest penalties. 

Electronic Data Interchange and Supply Chain Management (SCM) will eliminate the cumbersome flow 
of paper requisitions, purchase orders, invoices, shipping/receiving forms, technical specifications, and 
other documents for the acquisition of Automated Data Processing Equipment (ADPE) by replacing 
paper forms with electronic equivalents. In addition, SCM will provide a seamless, event-driven process 
that will save time and money. The user organization, DFAS, and Procurement can improve the 
accuracy and flow of information, which is essential to these organizations, by using the 51 1 
(Requisition) transaction set to replace the Form 9 and the General Accounting Office (GAO) approved 
electronic signature/security system to provide for security and signatures. Usina the AF MADES II/EDI 
system. Procurement will be able to send accurate and reliable purchase information in the form of the 
850 (Purchase Order) to the Trading Parmer (vendor). The Trading Partner will send an .Advanced 
Shipping Notice (.ASN ), (transaction set 856 Ship Notice Manifest) to the Base Warehouse, thus 
Jillowing the Warehouse to promptly notify all interested parties of the date and time that the ordered 
equipment will be arriving. The ship notice manifest contains bar code information and related purchase 
order data which corresponds with the item ordered. The Warehouse scans the Bill-of-Lading off the 
packing slip which is then compared to the original 850 purchase order. An American National 
Standards Institute (ANSI) X12 861R, Receiving Certificate, sends receiving information to 
Procurement and DFAS which can update the Air Force inventory tracking system (Integrated Product 
Management System (IPMS). After completion of end user acceptance, an ANSI XI 2 861 A, Advice 
Acceptance Certificate, is sent to DF.-VS so payment can be made to the Trading Partner. This process 
helps alleviate interest penalties and other costs. The use of the ANSI X12 854 will be used to notify the 
Trading Partoer if a delivery discrepancy occurs. The ANSI X12 997, Functional Acknowledgment, is 
required for all transactions. The collection of the 997 v^riU be used to create audit trails. The project will 
include a shared database assembled using EDI standards and other Commercial Off The Shelf (COTS) 
tools. 

This-project team consists of key personnel from Procurement, DFAS, Air Force Audit Agency 
AFC4A, and inputs from the GAO. » 
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PSA: Procurement . ' 

Lead DoD EC/EDI PM: Air Force, POC LT Matthew K. Miller 
(310) 363-2080 DSN 833-2080 

Technical Lead: Mr. Steven J. Lucks 
(310) 363-1155 DSN 833-1155 
Transaction Sets: 

• 511 Requisition 

• 850 Purchase Order (MADES liver. 3010) 

• 854 Shipment Delivery Discrepancy 

• 856 Ship Notice/Manifest 

• 861 Acceptance Certificate/Receiving Advice 

• 997 Functional Acknowledgment 

Status: Prototype (proof of concept) 

HaxdvmQ and software upgrades. Contract Labor, component upgrades (HW/SW under $15K) and 
education. 



PROJECT 95ARM 001 
ACQUISITION SUPPORT PROGRAM (ASP) 
PREVIOUSLY IDENTIFIED AS 95NAV017 
JOINT ACQUISITION MANAGEMENT SYSTEM (JAMS) 

In keeping with the facilities of the EDI technology, the ASP project is being developed to operate 
independently from existing application systems in order that the prototype can he exported to other 
sites. The project is led by the Simulation, Training and Instrumentation Command (STRICOM)- the Air 
Force panner is Eglin Air Force Base and the Navy partner is the Naval Air Warfare Center-Trainin^ 
Systems Division (NAWCTSD) and a second Army partner is the Army Missile Command (MICOM) 
We will also work with the Defense Information Systems Agency (DISA), the Defense, Finance and 
Accounting Service (DFAS), and Defense Contract Management Command (DSMC) on this project 
The EDI project is being managed under the Acquisition Support Program (ASP) umbrella, as this is the 
application in use by STRICOM and NAWCTSD and under evaluation by Eglin Air Force Base ASP is 
a modular toolset which provides the following functionality: 

• Integrated Management Information System (IMIS) - An integrated svstem for project 
management and tracking. 

• Procurement Information Systems Management/Acquisition Professional (ProMIS/AcqPro) - 
Supports acquisition package development with ready access to an acquisition librarv includine 
key acquisition regulations. ' 

• Proposal Evaluation Tool (PET) - An automated multi-user source selection toll desiened for a 
paperless environment. 

• Automated CDRL and Tracking System (ACTS) - An automated tool supporting the development 
and tracking of Contact Data Requirements List (form DD 1432) 

• Acquisition Tracking System (AcqTrack) - Provides members of program/project offices access to 
current information regarding project status. 

The purpose of the systems acquisition EDI initiative is to incorporate EDI transactions for the entire 
project life cycle beginning with the RFP. 

PSA Procurement 

Lead DoD EC/EDI PM: Army, POC Donna Felix 
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(407) 384-3799 
Transaction Sets: 

• 196 - Contractor Cost Data Reporting 

• 850 - Delivery Order 

• 810 - Invoice 

855 • Delivery Order Aclcnowledgment 

• 839 - Project Cost Reporting 

• 860 - Delivery Order Change 

• 840 - Request For Proposal 

• 865 - Delivery Order Change 

• 843 - Response To Request For Proposal Acknowledgment* 

This project will prototype 3050 federal implementation conventions for those transaction sets marked 
with an asterisk above. In order to achieve the extended enterprise with industry usmg EDI transactions, 
the project will include some transactions not funded by OSD at STRICOM which will include: 
Contractor Cost Data Reporting (196), Project Schedule Reporting (806), Project Cost Reporting (839), 
and Specifications/Technical Information (841). STRICOM and its partners will coordinate with the 
designated OSD lead for these transactions. 

Status: Prototype 

The Air Force and Navy are currently evaluating proposed prototype weapons/training programs. The 
following Army prototypes and industry trading panners are as follows; 

MICOM rWeapons Svstems) Trading Partner 
Patriot Missile System Loral-Vought, Raytheon 

STRICOiM Trading Partner 

Advanced Distributed Simulation Technology (ADST) Lockheed Martin 
Test Support Network (TSN) GTE 

Fire Support Combined Arms Tactical Trainer (FSCAT) Hughes 
Battle Lab Reconfigurable Simulation Initiative Hughes 



PROJECT 95DCA 001 
ELECTRONIC PRICING 

Manufacturers frequently change the packaging of specific grocery items. In addition, promotions, sales, 
and coupon usage routinely alter the price of many items, Thus, prior to electronic pricing the Defense 
Commissary Agency (DEC A) devoted significant resources to item pricing and maintenance activities, 
primarily at its regional offices. DECA processed more tiian 1.1 million price quote sheets for item 
pricing each year. Under die manual system, each of die six regions would individually receive the price 
quotes from manufacmrers and brokers and key-enter tiiem into their regional DECA Integrated 
Business System to be electronically distributed to all conmiissary stores located within their regions. 

The electronic pricing process eliminated the need for pricing at the six different regional locations. 
Manufacturers and brokers transmit price changes to DECA Headquarters using the 879 (Price Change) 
transaction set. Prices are validated electronically and non-matching items are retumed to the vendor"^ 
using die 824 (Application Advice) transaction set. This system has improved the efficiency and 
effectiveness of maintaining the catalog master file and has significantiy reduced pricing errors between 
DECA and commercial manufacturers. This process eliminated the need to perform price and item 
maintenance which had been performed at multiple DECA locations for an annual cost avoidance of 
5270,000. 

DEGA strongly encourages all business partners to send their prices electronically. Trading partners 
must be able to electronically send prices to DECA prior to DECA administering the Resale Ordering 
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Agreement (ROA) and allowing them the option of using the Electronic Funds Transfer (EFT) process. 



DECA also offers vendors who send prices electronically the opportunity to use the Delivery Ticket 
Invoice (DTI) payment method using the delivery ticket as a basis for payment, eliminating the invoice 
from the bill-paying process. No documentation is required for payment, eliminating 1 1 associated 
processing and mailing costs (or EDI costs for the electronic invoice) including the costly reconciliation 
process for both DeC A and the manufacturer. 

The electronic pricing will eliminate the need for manual data entry of monthly prices for over 200,000 
resale items at six regional offices. There are many related cost avoidances that are gained by using this 
method of pricing versus the manual pricing that cannot be directly accounted for in the total ordering, 
receiving and selling process of DeCA's resale items. 

PSA: Procurement 

Lead DoD EC/EDI PM: Defense Commissary Agency, 

POC Tom Hackett 

(804)734-8351 

Transaction Sets: 

• 824 Application Advice 

• 889 Promotion Announcement 

• 879 Price Change 

• 997 Acknowledgment 

• 888 Item Maintenance 

Status: Deployment 

Software Development and DeCA wide 



PROJECT 95DCO 001 
EC/EDI WITHIN DECCO 

Currently, the Defense Information Technology Contracting Office (DITCO) has four functional areas: 
Pre-Solicitation, Solicitation & Award, Contract Administration, and Close-Out. DITCO performs the 
majority of procurements for telecommunications services in DoD and Federal Information Resource 
Management Regulation (FIRMR) resources. These procurements are done using manual methods and 
the Defense Electronic Bulletin Board Service (DABBS). A large number of these procurements of 
circuits are dme-sensitive requiring the fastest possible processing and contractor response time 
available. 

Under the DITCO Electronic Data Interchange (EDI) project, application interfaces will be developed to 
integrate EDI capabilities within DITCOs existing CustomerA^endor Interface (CVI) and network 
infrastructure. EDI will facilitate an expansion of the commercial industrial base supporting DITCO, 
provide greater and faster competition, reduce data entry time and costs, enhance data integrity, and 
provide greater access to common shared databases of contract and financial data supporting the 
teleconununications procurements. 

The improvements will be in the areas of one time data entry, and improved financial and accounting 
services. The one time data entry will improve the effectiveness and efficiency of DITCOs operation by 
reducing the opportunity for data entry errors, eliminating duplicate entries and enhancing the integrity 
of the stored data. Our financial and accounting services will be enhanced by the implementation of 
Electronic Fund Transfer with both our customers and suppliers. This conversion will enhance the 
accuracy of our financial record while reducing the required labor hours. 

PSA: Procurement 
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Lead DoD EC/EDI PM: Defense Commercial Communication Office (DCCO), 
POC Lisa Buckmann (618) 256-9587 
Transaction Sets: 



• 81 1 Consolidated Service Invoice 

• 850 Award Document 

• 820 Payment Order/Remittance Advice 

• 855 Acceptance 

• 824 Application Advice 

• 860 Modification 

• 836 Procurement Notices 

• 864 Test Message 

• 838 Trading Partners Profile 

• 865 Response to Mod & Changes 

• 840 Solicitations 

• 869 Order Status Inquiry 

• 843 Contractor Responses 

• 870 Order Status Report 

• 997 Acknowledgment 

Status: Prototype 

Security Risk Assessment, Data Modeling/ Interface with 840 and 843 Transaction Sets 
Modeling/Interface with 810, 820, 850,and 856 Transaction Sets, Training and Supplies 



PROJECT 95DLA 009 
SUBSISTENCE MULTI-LINE INVOICING 

Project: » 

To understand the current project it is best to start with a little history of Electronic Invoicing in 
Subsistence. The original Subsistence Electronic Invoice process was developed around Brand Names. 
This logic involved a single delivery per invoice. The original testing of the project was with Proctor and 
Gamble (P&G) but switched to Del Monte when P&G was unable to provide Contract Line Item 
Numbers (CLIN) back to Subsistence. These CLINs were needed to produce the results of line item 
accounting that the Government fmancial community wanted. The project was in the middle of testing 
with Del Monte when funds were e.xhausted. It was discovered during this time frame that P&G was not 
the exception but rather the rule in not being able to provide CLINs back to DPSC. Most of the food 
industry did not keep these numbers in their systems and were unable to provide them when we 
requested. 

Any electronic solution is only as good as the number of documents and partners that are actively using 
the system. Because of our original problems with getting trading partners who could provide CLINs 
back to DPSC, the focus switched to developing a system which did not require vendors to provide 
CLINs back. The recent decision in using a summary invoice for prime vendor alleviates the need for 
this logic because the CLIN count will always be one. In addition, in the development of a distributed 
Electronic Invoice process (fresh fruit and vegetables (FF&V) Business Process Improvement (BPI) 
process, DPSC was able to solve the problem by providing the contract line items numbers back to itself. 

The Subsistence Multi-Line Invoicing project is an enterprise project which adds electronic invoicing 
functionality to the current payment process. The Defense Systems Design Center (DSDC) has been" 
chosen to do the programming for this project because it was the most cost effective solution. The fUnds 
for this project will be used to fund the project being done by DSDC. 

The current project is the link between the logic and the newer contracting methods of long term 
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contracting It builds on the functionality of the original project and allows the original module to accept 
multiple dehvenes on the same invoice. This project is based on the current commodity set-up and 
targets the high volume, labor intensive areas first. 

TTie programming involves modifications to current systems which allow processing of multiple call 
(delivery) mvoices m heu of the single line processing which was developed for Brand Name In 
addition, fiindswiU be used to program links between this process and the data which will be provided 

•^.uvri^^ ^?n^^* w ^^''^ steps are completed, the process wiU be tested and trading partners 
m the FF&V and Prime Vendor areas will be added. ^ 
PSA: Procurement 

Lead DoD EC/EDI PM: Defense Logistics Agency, 
POC Jeffrey L. Nienstedt (215) 737-3860 

Transaction Sets: 

• 810 Invoice 

• 805 Award Document 

• 820 Payment Order/Remittance Advice 

• 850 Grocery Products Invoice 

Status Prototype 
Deliverables: 

TTie deliverables for this system consist of a working Electronic Invoice process for FF&V Prime 

automation of invoice data input for FF&V trading partners from our 

FF&V BPI. 



PROJECT 95UMC 005 
BLOUNT ISLAND EDI 

The primary mission of the Blount Island Command is to plan and coordinate logistical support for the 
Maritime Prepositionmg Ships (MPS) program and the land prepositioning program in Norwav 
Currently, the procurement of supplies and services are accomplished through a manual and paper based 
purchasmg system. These requisitions are handed off to the purchasing office and are manually keved 
into the procurement application for processing. This results in lona lead time and delays for the ' 
upload/download and maintenance cycles of ships that provide support to contingency forces. 

The objective of this Electronic Commerce,/Electronic Data Interchanse (EC/EDI) project is to provide 
the Blount Island Command personnel with an information systems which will automate their efforts to 
procure required supplies and services in support of the MPS Program and to manaae lar«»e single 
cost-reimbursement contracts. The target system for the procurement of supplies and services is the retail 
version of the Integrated Techmcal Item Management arid Procurement (ITIMP) system. The target 
system for the management of cost-reimbursement contracts is the System for Inteerated Contrart 
Management (SICM). 

Implementation of the target EC/EDI information system interchange svstem will provide Blount Island 
with a ftiUy automated procurement system. This will reduce lead times', costs, delays, and enable the 
customer to establish a "just in time" inventory capability. In addition, the automated svstem will 
improve the management of logistics by providing accurate and timely data. 

PSA: Procurement 

Lead DoD EC/EDI PM: Marine Corp, POC Steve Butt (912) 439-5575 
Transaction Sets: < 
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• 840 Solicitation' 

• 843 Quotation 

• 850 Purchase Order 

• Hi f S^^f Delivery Discrepancy Information 

• 856 Ship Notice/Manifest 

• 857 Shipment and Billing Notice' 

• 858 Shipment Notice 

• ^<=<^ep^c« Certificate 

• 862 Shipping Schedule 

• 997 Acknowledgment 
Status: Deployment 

Hardware & Software, Installation of Re tail Version of ITIMP or SICM 

PROJECTS 95NAV 002 

CONTRACTOR PERFORMANCE REPORTING 



Inamemorandumdated25 January 1995 the Under <5i»rrPt!,r„«fr>-ft. r a 

based system, fir program managemS NAV^"J^d NAVm^iS^Jl^^^^^ 7"' '5 
prototype tests to exchange program manasement dSwi>h have successfully conducted 

great deal of time'and e&n is'^cSy eXK^dTuS^^^^^^^ ""^"P'' '="P'='«^- A 

into a variety of government LSfor Sj^f eost performance and schedule data manuaUy 

disk) the currem proprieTarv forSiats ^^00^ o (on floppy 
Information Processing St^dard (HPS) 161 "TrS^^^ T^nLf ^ '^''"'^^ Federal 

often requires the contoictor trsuDolv t^^^ nn 7 f 7?* ^^""^ of standardization 

generating the data required brth? gov«5.^nt^^^ ^^P" ""^ electronically, increasing the cost of 

an application neutral foniat across all proeiams ind sl^ ces Thl^f S?.!^^ management data in 
fonr^vhile a, the same time '^^0^nUi^Z'^:^\flSS!T.^;^t7r^^T^ " 

EDI will eliminate manual document processing massive data entrvAfTnrtc „orj _. 
resolution. I, wil, al» provide a meanS to standL^?,^'orgl^:S 
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°° ^P*"^'' ^^."^ of interest without wading through pages of extraneous data. The 
overall cost performance reporting process can be streamlined into a faster, more efficient, and less 
costly system. 

PSA: Procurement 

Lead DoD EC/EDI PM: Navy (NAVSEA), POC 
Mr. Mourad Yacoub (703) 602- 1 679x1 54 

Transaction Sets: 

• 839 Project Cost Reporting 

• 806 Project Schedule Reporting 

• 997 Functional Acknowledgment 

Status: Prototype 

Draft 806,839, and Analysis Reports. 

NAVSEA Prototype between AEGIS Destroyer DRPM and Ingalls Shipbuilding initiated January 1995. 

NAVAIR Prototype between V22 FMO & Bell Boeing initiated November 1 995. 

Final versions of all ICs.Testing with NAVSEA/Bath Iron Works scheduled to begin early 1996. 

Continued expansion of Navy implementation. 

Prototypes in AF and Army PMOs. 



PROJECT 95DL A 001 
PROGRESS PAYMENT REQUEST 

The current system requires manual data-entry as well as manual interface with the Mechanization of 
Contract Administration Services (MOCAS). This process has resulted in the governmentTccSndlv 
c^K.""'" ''^^'^^'^^ of±. Prompt Pay Act, and has had an adverse in^p^ on the fcSv^Js 

This project, when implemented, vvill allow contractors to electronically submit their progress oavment 
requests and Material Receiving Reports (DD 250) to the Administrative ContraSin' OfSe Ld 
^ i^^^'i^^'fuP" P^°p«/!"g and data entry. The progress payment aspect of this project is 

rdavs%oTda^^^^ Sn In " ' "'rr P'^'"^"^ P^^^^'^^^^ time, a? the actWit?, ^m 16 to 
-U days to 2 to 4 days. The DD 2^0 aspect of this program is currently under the functional testing stage. 

PSA: Procurement 

Lead DoD EC/EDI PM: DLA, POC Ron Kunihiro (703) 767-6338 

Transaction Sets: 810 Invoice 
856 Shipment Notice 
997 Acknowledgment 

Status: Deployment 



PROJECT 95DLA 003 
PLANT CLEARANCE AUTOMATED 
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REUTILIZATION SCREENING (PCARS) 

The current system requires the contractor to mail the list of excess government property to the Plant 
Clearance Office where the information is manually processed. This process is labor intensive and takes 
approximately one to two weeks before an available items appear in the catalog. 

The revised system will enable the contractor to transmit excess government property information 
electromcally with all changes to the catalog appearing the next business day. The enhanced system will 
not only save time, money, and labor, it will provide more visibility to the excess property records, 

PSA: Logistics 

Lead DoD EC/EDI PM: DLA, POC Ron Kunihiro (703) 767-6338 
Transaction Sets: 

• 180 Return Authorization 

• 511 Requisition 

• 856 Ship Notice/Manifest 

• 870 Order Status Report 

Status: Deployment 



PROJECT 95NAV 006 
CONTRACTOR COST DATA REPORTING SYSTEM 

The current process requires the paper transmission of a quarteriy or semiannual Contractor Cost Data 
Reports (CCDR) and Contractor Performance Reports (CPR) for dozens of large scale production 
contracts that can average over 200 pages in length. Data currently comes in multiple contractor 
determined formats (although there are specific instructions and DoD formats) on a series of multiple 
torms. These reports are often late with the users being required to rekey data into the analysis 
application. This rekeymg limits time spent on the actual analysis. There is a current backlog of four 
yfF^ ofCCDR finals which have not been automated due to lack of funding for the manual'data entry 
ettort. This scenano restricts the cost analysts to using only portions of the data in a timely manner 
Quality of cost estimates could be substantially improved if all CCDR data were available in an on-line 
database immediately after receipt. 

Electronic Data Interchange (EDI) of contractor cost data will eliminate manual document processing 
and massive data entry efforts while providing for more accurate validation and greater error resolution 
The proposed system will provide a means to standardize reponing formats and data requirements and ' 
allow analysis of the data to focus on specific areas of interest with out wadina through pa^^es of 
e.xttaneous data. The overall CCDR reponing process will be streamlined mto^a fasted, rnore efficient 
and less costly system. With the emergence of Performance Analyzer (PA) as a standard within DoD 
the effects of EDI are even more pronounced since PA has a built-in interface to the ANSI XP 839 ' 
Project Cost Reporting" transaction set. 

The ability to share contractor cost information among the various Navy, and eventuallv DOD 
organizations will be significantly enhanced. This program is designed to expand a Naw/OSD initiative 
into an integrated multi-service effort. The project will include a shared database assembled usincr EDI 
standards. The 196 "Contractor Cost Data Reporting" transaction set was developed bv the ASC XP 
Government Subcommittee and consisted of OUSD(PA&E) and Naval Air Svstems Command 
personnel as well as representatives from private industry. 

Estimates of cost savings indicate that after only two years of direct ftmding from OUSD (AR-EC) this 
project will begin to show a posiuve net benefit to the Navy. Beginning in FY 97, net cost benefit is 
expected to average nearly 560,000 per year. 
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PSA: Procurement 

Lead DoD EC/EDI PM: Navy, POC Michael Lamatrice 
(703)604-3611 x2558 

Transaction Sets: 

• 196 Contractor Cost Data Reporting 

• 806 Project Schedule Reporting 

• 839 Project Cost Reporting 

Status: Prototype 

Hardware, Software, and Analysis, Systems, Integration, & Program Management 
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APPEiNDDC F - DOD LOGISTICS 



1.0 Background 
2.0 Basic Requirements 

J^^^?l}l^^r\''^^nn^vf^i^^^ ^i^S fimded, at least partially, and supported by 

pUSpCARy^C). the DOD Electronic Commerce Office. Attachment 1 to this appendix contains a short 
descnption of each of them and also identifies which XI 2 transaction sets are being used. 



PSA 




riUJCLl ilUC 


Logistics 


95DCA 003 


Distribution OCONUS Ordering 


Logistics 


95DLA 008 


Hazardous Material Information System 


Logistics 


95DLA0I5 


BOSS Hazardous EDI 


Logistics 


95DLA016 


Export Transportation 


Logistics 


95DLA 020 


Automated Bidset Sheets Interface 


Logistics 


95NAV 008 


Non-standard Demand Reporting 


Logistics 


95NAV010 


Non-standard Materiel Request 


Logistics 


95NAV 012 


Materiel Safety Data Sheets 



3.0 Analysis and Considerations 



Attachment 1 to Appendix F 

, Logistics Projects Supported by the DOD Electronic Commerce Office 

PROJECT 95 DCA 003 
DISTRIBUTION OCONUS ORDERING & RESALE SYSTEM 

Defense Commissary Agency (DeCA) identified an opportunity to standardize and improve the 
etficiency and effectiveness of the Military Standard Requisitioning and Issue Procedure (MILSTRIP) 
process. DeCA reengmeered the entire process and the resulting product was the "DeCA Overseas • 
Ordering and Receiving "(DOORS). DOORS is an Efficient Consumer Response fECR) 
application within the DeCA Interim Business system (DIBS). Reduced to its essentials, DOORS is the 
mechanism which DeCA uses to replenish, either directly or indirectly, stocks of semi-perishable and 
penshable items m overseas commissaries. 

DOORS provides this capability by electronically linking the Overseas Order Points (OOPS) to 
distnbutors and nianufacturere located in the United States through the Order Processing Pomts fOPPS) 
located m the Umted States. This electronic linkage of OOPs and OPPs to the distributors and 
manufacturers who supply the products results in rapid stock replenishment bv direct response to patrons 
demand coupled \vith the maintenance of much lower inventory levels in overseas areas In developing 
and deploying DOORS, DeCA moved away from the Defense Personnel Support Center (DPSC) as the 
means of providing overseas commissary stock replenishment. 

Making this shift to DOORS is another application of DeCAs basic replenishment philosophy, which 
calls for pullmg orders in direct response to patron demand, rather than "pushing" stocks overseas for 
reasons only indirectly related to patron demand. This is one more demonstration of DeCAs 
commitment to offer the very highest quality service to our patrons through an internal initiative 
complemented by cooperation of our industry trading partners. Both our patrons and our industry trading 
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partners are better sensed by consistenUy higher levels of stock availability, fresher products and 
quicker appearance of new items that DOORS makes possible. Additionally, through DOORS DECA 
can deliver a more cost effective benefit: The cost of the third-party support relationship with DPSC is 
tTISi'hi^AT'^ -rT^SJf '° ^°^^)' shorter order-ship dme 

On Decemljer 21. 1995, DeCA accepted the National Perfonnance Reviews Hammer Award for success 
m remventmg government DOORS was a major player in DECA success toward vnm^g^H^T 

PSA: Logistics 

Lead DoD EC/EDI PM: Defense Commissary Agencv 
POC Tom Hackett '' 
(804)734-8351 

Transaction Sets: 

856 Advance Ship Notice 997 Acknowledgment 
875 Grocery Product Order 

Status: Demonstration & Prototype 

Software Development and Prototype at Guam commissaries. 



PROJECT 95DLA 008 
HAZARDOUS MATERIAL INFOR^UTION SHEETS (HMIS) 

Objective: 

m^nc^ ^° ^ "l^*^'^ ^o^s'stent usage of the ANSI X12.848 Material Safetv Data Sheet 

Project: 

Trading partners seeking to do business with the government electronicallv should use these ICs in the 
design of their electronic hazard communication programs and translation systems. The Federd 
Govenunent facilmes diat are prepared to accept MSDS via EDI will use these specified formats. 

Sfe^'S f'^i''' ^ apparently successful offer to submit a Material 

Safety Data Sheets (MSDS) to the solicitor for hazardous material. The Occupational Safetv and Health 
reSSiemSS(?.n^^^ Communication Standard (HCS), describes^he p^^S^d bS? 
requirements of MSDS. The enclosed implementauon conventions (IC) provide a method for satis W 
these requirements electromcally using the American National Standards Industrv (ANSI) X^^ 
iS'^erSLT^^Ir^^^^^^^ ^^rS'^^i l"^'^^^,^8e (EDI). While certain data^aJfm^J^or;^^^^^ 
whaUs ?e&ie^i^ th^^^^^^ themselves are not an attempt to mandate a data set beyond 

Ki^f'r °' however, specify the logic structtire, data format, and level of detail consistent with the 
Federal Governments information systems. In addition, usage of two of the ICs is nredicated utTon the 
adoption of the ANSI Standard Z400.1. (Material Safety Data Sheets PrepLa^o^ S Fe^^^^^^ 
&H^&ti"^^^^^^^^^ but is Obligated to accept any MSDS compliant under 

The purpose of these ICs is to provide a method for consistent usage of the ANSI XP 848 TMaterikl 
fhf I? transaction set. The conventions were developed in conjunction iii ^opS 

Je-Join Pettoleum Industiy Data E.xchange (PIDX) and Chemical Industr^ Data Exchange (CID>0 
Matenal Safety Data Sheet Working Group. Tliey are consistent in contem and intern vSh the guiSnnes 
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ffcnc f ^ 1."^^°^ ^'^"P^- ^^^^"^^ lack of standardization of hardcopy 

MbD5> tormats among the different industries and individual corporations, the Federal Government 
deemed it appropnate to approach an electronic format in partnership with industry to achieve both 
maximum acceptance and usage. 

Trading partners seeking to do business with the government electronically should use these ICs in the 
design of their electromc hazard communication programs and translation 

systems. The Federal Government facilities that are prepared to accept MSDS via EDI will usethese < 
specified formats. 

PSA Logistics/Environmental Security 

Lead DoD EC/EDI PM: DLA, POC Gene Cogdill (703) 767-2608 
Transaction Set: 848 MSDS 
Status: Demonstration 
Deliverables: 

Reports to evaluate the use of ongoing commercial efforts to standardize the exchange of MSDS bv the 
govermnent. ^ ^ 



PROJECT 96DLA 015 
BOSS HAZARDOUS EDI 



Initiative: 

The Base Operations Support System (BOSS) Hazardous is a post award contracting system for 
hazardous waste disposal Processes handled by BOSS include generation of deliveS. orders and 
modifications to arrange for the pick-up. transportation and disposal of a waste stream, monitoring the 
movement of the waste through shipment manifests, receiving contractor certificates of disposal 
authorizing contractors to invoice for payment and transmitting information to Defense Financial 
Accounting System (DFAS) Center to make disbursements. The currem system of accounting for and 
ttackmg, hazardous waste disposal is a manual, and labor intensive, paper based system. Hard copy 
delivery orders and modifications are printed, signed, copied, faxed, and mailed to the contractors 
DFAS, our Defense Regional Management Offices (DRMO) and the generators, as required. Hard copy 
manifesting is mailed to the concracting offices. When received the manifest line items are checked • 
against the delivery orders/modifications, and reviewed to insure proper handling and disposal. When 
this venfication process has been completed the information is keyed into our database svstem One to 
many relationships exist between line items and manifests. Each time a waste item is mo'ved until final 
disposal, a mamfest is required. One line item may have multiple manifests due to movement of the 
waste storage at alternate facilities, treatment, and disposal. Each manifest line item is entered 
individually into the system. Because of the requirement to re-key data, there is a high likelihood of 

Under an electronic data interchange (EDI) environment, the enture process would be streamlined 
Delivery Orders and modifications will be automated using 850 "Purchase Order" 855 "Purchase Order 
Acknow edgment". 860 "Purchase Order Change Request" and 865 "Purchas^^Order Chiige 
Acknowledgment trmisactions sets. In lieu of issuing hard copy delivery orders/mods to the DRMOS 
m a'k^^""^ ^ f P'°FTy Recounting system. Defense Automated Information System 

DAISY). The program will be expanded to include the capability for EDI exchange of hazardous waste 
line Item detail to our generating activities. This will enable DRMS to streamline Sid automate the 
certification of manifesting data using EDI. When implemented BOSS Hazardous will automatically 
match mtenm and final manifest line items with pickup manifest line Items to facilitate accurate and 

T?.Kwl\??t K y'''"^.^?'^^^ ff'^ ^""y requirements. Requirements to incorporate Portable 
Sv Sftei ffi>^f^^°^-|^^ (hand-held computer) and barcoding are also being rese^ched and more 
clearly defined. DRMS has identified the requirement for imaging equipment to satisfy leoal/litieation 
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issues for third-party/direct environmental clean up. Full integration of BOSS Hazardous data into the 
Single Hazardous Input Program (SHIP) is alsd planned. Payments will be authorized using evaluated 
receipts settlement procedures and disbursed using electronic funds transfer (EFT). These processes will 
result m a more streamlmed busmess process, paper reduction, and enhanced monitoring capabilities to 
track hazardous waste from cradle to grave. 

Cuirent status Functional testing of the 850 Transaction Set "Purchase Order" is complete Awaitin^ 
Q^fn i^Jf notification from pilot trading partners to begin production parallel test. Functional testing^of 
860 Purchase Order Change Request" is expected to begin mid-January, 1996. Currently finalizing 
streamlined mamfesting procedures and identifying requirements for evaluated receipts settlement the 
Logistics Management Institute (LMI) is working to ensure DRMS requirements are included in 
implementation conventions that are being developed. We anticipate that the testing of EDI tiransaction 
sets relating to mamfesting and evaluated receipts settlement will begin in the May-June 96 time fiame. 

PSA Logistics/Environmental Security 

Lead DoD EC/EDI PM: DLA, POC Sherrv Underwood 
(616)961-7229 
Transaction Sets: 
810 Invoice 

820 Remittance 

860 Purchase Order Change 
850 Delivery Order 

861 Material Receipt 

855 Acknowledgment 

863 Certification of Disposal 

856 Manifest 

865 Acknowledgment 

Status Demonstration 
Deliverables 

Functional Testing Programming & Mapping Studies & Analysis, Imaging Hardware, Integration of 
rJUbb into Single Hazardous Input Program 



PROJECT 95 DLA 016 
EXPORT TR.\NSPORTATION (EXTRA) 

Currently, business practices at the Defense Personnel Support Center (DPSC) related to the shippin<T 
tracking and monitonng of troop issue and defense subsistence cargo movements are a largely manuli 
processes which is tied to paper based and telephonic systems. This results in a clerical and 
administrative burden which is manpower intensive and limits the time available to perform more 
meaningftil logistics management functions. 

This project will develop a personal computer (PC) based system for the electronic processing of car^o 
movement documents. The system will provide for enhanced shipment tiacking as well as facilitating 
the timely requisition, procurement and transportation decisions in the DoD supply and transportation 
communities. As the distribution application determines how the requisition will be supplied fi e 
through source load militarv distributor, depot, or Defense Subsistence Office (DSO) shipment! * the 
t A 1 KA system will determine initial cargo van requirements for advance bookings. 

When the contract award data on the material being shipped is available, final van requirements are 
determined by EXTRA and submined directly to the overseas terminal operators. Capitalizing on 
conmiercial earner automation efforts, DPSC will maintain in transit visibilitv on DOD shipments 
Using o 13 Stams Detail transaction sets input either through EDI or other communications means the 
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commercial earners will provide continuing status reports from the time of pick up to and including 
delivery at final destination. TTieseevente include port of entry (POE) actual time of arrival (ATAfand 
POE actual time of deparmre (ATD): EXTRA i-eports will be requested by and produced on Cathode 
Ray Terminals (CRT) on an as needed basis with the ability to print on demand as minimally necessary 
Real time processmg will be utihzed for those reports generated on a daily basis; the option for real time 
or batch processmg will be supported for major reports generated less frequently. 

PSA: Logistics 



Lead DoD EC/EDI PM:.DLA, POC Anthony Travia 
(215)737-2652 

Transaction Sets: 

214 Carrier message 

300 Reservation 
315 Status Report 

301 Confirmation 
856 Ship Notice 

858 Shipment Information 

Status: Prototype 



PROJECT 95DLA 020 
AUTOMATED BIDSETS INTERFACE 



nht » f ??rf S-^ ^ million m annual savings through the deployment of the Automated 
nl"^ n.^. f?nf °f ieJ^"^^^'* electronic dissemination of Engineering 

Data Lists (EDLs), Technical Data Packages (TDPs), drawings, and technical information in support of 
spares reprocurement sohcitations. The ABI pulls data from tiie migratory systems Joint Engineering 

X Control System (JEDNUCS), Standard Procurement Svstem (SPS) 

and the Techmcal lnformation Storage and Control Application (TISCA,); and then electronically 
transmits the 841 (SpecificationyTechnical Information) Transaction Set under tiie 3050 conventions to 
tiie trading partner. ABI is a major step in the DoD mandated "Continuous Acquisition and Life Cvcle 
Support/Electronic Data Interchange" (CALS/EDI) initiatives. Standard EC/EDI transmissions to iradins 
partners will reduce vendor conversion costs and shorten procurement lead-times. Another benefit to tiiis 
automated process is the improved quality and reduction in errors. 

The ABI functionality was successfiilly tested during June 1995 in Columbus, Ohio at the Defense 
^°"Sf^"'°".,S>;PPly Ce^^^^^ the test the automated bidsheets interface pulled data from 

Jh 1 UCb, built the EDL, and electromcally transmmed the data cut to a Value Added Network (VAN) 
Am ^^'1^^^^'°^' ^°??^"^.^,^L!?-^SC^as elated by the success of the test, and tiie potential of the 
ABI. The test went well!", said Elliot. "The challenge now is to modify tiie business practices botii in 
tiie government and private industry to take full advantage of tiiis technology." Rear Admiral Elliot 
recogmzes tiie unmediate savings to tiie government tiirough tfie utilization of tiie ABI and fiillv 
Sid DGSC^?l^Sli7vA ^ ^° ""^^"^ at DESC, Dayton, OH; DISC, Philadelphia PA;. 

Under the close supervision of iVIr. Phil Altman, Program Manager, HQ DLA, ABI will be deployed to 
the tiiree DLA centers. Furtiier dissemmation of tiie ABI will be pursued under tiie new name of 
Dissemination of Digitized Drawings for Reprocurement (DDDR) with potential deployment DoD wide. 

S^A'^L^r^^^T^"^l®wJ°P^'l.^°"^ die joim efforts of tiie Federal Government and private industry 
DLA and LOGICON (formally SYSCON) are coordinating tiiis effort to bring this product to 

PSA: Logistics ' 
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Lead DoD EC/EDI PM: DLA, POC Philip Altaian (703) 
767-2601 f K } 

Transaction Sets: 841 (3050) Specifications/Technical 
Infoimation 

Status: Prototype to Demonstration in FY96 



PROJECT 95NAV 008 
NON-STANDARD DEMAND REPORTING 



Procunng activities report non-standard purchases to the Navy Inventory Control Point (NAVICP) for 
the piloses of haying a National Stock Number (NSN) assigned to items purchased that had been 
identified by their local stock numbers (LSN). This NSN identification reduces the number of 
non-standard local procurements and provides the benefits of centralized management of material. 

Currently these reports are received in an 80 column format, as prescribed by 

Military Standard (MILSTD), with a document identifier code of "BHJ", (BHJ is a three digit document 
idenufier code assigned to intra-Navy transactions related to inventory control systems ) These 
Sf.H?'^^^^^ ^t^'^^f^ 'T"^ the purchases of non-standard material (no NSN has been 
assigned). MILSTD s 80 column limitation inhibits the ability to accurately catalog the item for stock 
numbenng because important data is often truncated (e.g., part number) or not transmitted due to the 
restnction of the Military Standard Transaction Reporting and Accounting Procedures (MILSTRAP) 
format. In addition reporting procedures are not standardized, and data is transmitted either ore- or 
post-award, depending upon the activity. Both pre- and post-award information is required as the 
^i^'^M u P!". n^i^ber may be obsolete and a replacement part purchased instead. Both part numbers 
should be cataloged under the NSN for cross reference purposes. Additionally, the originTqSS from 
the requisitioner is required to ascertain the demand vice the amount actually purchased In many cases 
the customer may only need "one each" of an item but the vendors minimum order quantity is hiaher 
This results m excess inventory of these non-standard items with no visibility of these excess items to 

t°h^ i^.Jl?'^^ f "'^^ u °f-S^ "^^""^ ""^^^ ^^^"^ system, has no meaning bevond 
the local activity. This results m the differem buying activities purchasing the same items with identical 
mimmum quantity problems. 

In order to correct the existing simation die Navy's initiative will develop a new procedure which will 
utilize the current Automated Procurement Accounting Data Entrv (APADE) process and Electronic 
Data Interchange (EDI). Which, when implemented, will pull specific elements from the APADE 
System to assist the activity in the accurate and timely identification of these purchases. This data will 
be transmitted directly to NAVICP in Mechanicsburg where it will compile product demand iXn^a on 
which will then be utilized to improve the Navy's cataloging. "uuraiauon 

The new format accommodates variable length data, and will be reported real-time on both requisitioner 
request and upon the avvard of a contract. Both pre and post- award data will be received. If the original 
requiremem for an obsolete item results m procuremem of its replacement, both part numbers will be 
cataloged under one NSN for cross reference purposes. If a local stock number is not reported, one will 

tn t?? Vf iH ;^rV.nr???°^^ ^ "s^^^fo. W^^Se a non-standard database which will be distributed 
to the field by NAVICP Mechanicsburg. Visibility of excess assets, caused by the minimum order 
requirements, via the local stock number should eliminate some of the buv requirements The cross 
' fu^"vrc>S °f o^'solete/replacemem part numbers also eliminates the need for many LSN procurements 
as the NSN will be reqmsitioned instead. New NSNs will be assigned to those items that meet the 
criteria. 



Implementation of a staridardized, electromc, real-time reporting system will result in improved supply 
support. Inventory cost, labor and local procurement efforts will be reduced. Use of variable length 
records and an improved data transmission will facilitate NSN assignment, provide non-standard 
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material visibility, and improve inventory management practices. This program will automate demand 
processmg and be expanded to accommodate specific service/DoD requirements and cataloging criteria. 

PSA Logistics 

Lead DoD EC/EDI PM: Navy, POC Diane Sechrist 
(717)790-2548, DSN 430-2548 

Transaction Set: 867 Product Transfer and Resale Report 
Status: Prototype 

DoD EC/EDI Funding: FY95 
S278K Mapping, Software, and Project 
Management Support 

FY96 

$249K Hardware and Project 
Management 



PROJECT 95NAV 010 
REQUISITIONING OF NON-STANDARD MATERIAL 

Prior to procurement of items of supply, they must be properly identified and described, either by the 
requisitioner when submittmg the original request, or by other personnel in the supply system at some 
f '^t^'^^^-cS' "^f screening" process. For material formally identified by 
-nn nSf ^"^^^i technical screemng is part of routine cataloging procedures. However 

over dOO.OOO non-staridard requisitions are submitted each year which have predominately required 
manual review for techmcal .screening. f j ^ 

While many of the Navy supply processes have been automated over the years, the non-standard 
requisitiomng process remains bound in a manual, paper environment. During visits to ashore and afloat 
activities to ascertam their need for more expediem technical screening methods, it was discovered file 
drawers full of old paper messages, cumbersome technical manuals, drawings and microfiche were still 
being utilized. The Fleet and Industnal Supply Centers (FISCs), working as regional providers of 
services, as well as individual screeners were not able to share data; therefore creating redundancy lone 
lead times and unnecessary delays in the procurement of non-standard items. ^ * 

As part of the FISC interweaving mitiative, a working group was established to examine further the 
feasibility of centralizing the function and identifying possible dollar savings without loss of service to 
the customer, perefore, the Naval Supply Systems Command (NAVSUP), in its cominuing efforts to 
reduce costs of operations through standardization, centralizatioii, and downsizing, adopted a 
methodology to consolidate the requisitioning process at the Naval Inventory Control Point (NAVICP^ 
with a Host module residing at NAVICP Mechanicsburg, the Central Techm\:al Activity (CTA) a 
customer support module at each user activity and a storefront module at each FISC to manaae 
problem-case requisitions. «»5 

The Automated Non-Standard Requisitioning System (ANSRS) is an automated (paperiess 
environment) program which performs a basic-level technical review (customer level) of each 
A^Scn^i?^^"^' S^nprates an electronic requisition, downloads requisition and forwards to the CTA/FISC 
»K V- A wT^n^f^'*^^"^ ^"^o^^"^ 'J?M°TIS electronic requisitions through the CTA and generates status in 
the NAVICP Document Stams File (DSF). Validations and edits are built into the svstem and 
^°"^""15f;°iL participants occurs via the Streamlined Alternative Logistics Transmission 
System (SALTS)/Electromc Data Interchange (EDI), and the Military Standard Transaction 
5f?oifxif?'VP= ■ Procedures (\nLSTRIP) via Uniform Inventory Control Program 
(UICP)/Umfonn Automated Data Processing System (UADPS)/Shipboard Uniform Automated Data 
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Processing System (SUADPS) transmissions, so as to maintain status and demand criteria. The svstem 
screens out exceptions and queues those items with inadequate data for manual review. As part of this 
process, ANSRS produces a database of all hon-standard requisitions, resident, maintained and updated 
at the CTA. A tailored version will be distributed via CD-ROM as part of the customer and 
FISC/storefront modules. As records on new items are added to the CTA non-standard database 
providmg historical data and past procurement history, the program will become more proficient at 
screening reqmsitions, expediting technical screening of subsequent requisitions for same or similar 
Items. Savmgs with respect to purchase of hazardous materials and storage of these materials will be 
realized smce each technical screener at the customer, FISC and CTA level will have access to technical 
mtormation identifymg these items and the methodology necessary to process them correctly. 

Implementing EDI within ANSRS will provide a standard format so that a system interface can be 
designed. This will allow customers to provide more complete and accurate information and reduce lead 
tunes and delays. In addition, EDI will allow the flow of non-standard demand data from the 
procurement system to the NAVICP. 

ANSRS is well into the developmental stage with its prototype date (March 1996) on track The 
centralization of the non-standard requisitioning process at the CTA will create a central repository for 
data to allow collection of part-numbered information, visibility of all part-numbered buys and will 
facilitate faster and more efficient service to the customer. In the long-run, as ANSRS propagates and 
assimilates users, the cost of processing non-standard buys will decrease and will ultimately drive down 
the total weapon systems support costs. 

PSA; Logistics 

Lead DoD EC/EDI PM: Navy, POC CDR Tom Williams ' 
(703) 607-0926 

Transaction Set: 5 1 1 Requisition 
Status: Prototype 

Project Management Support, Mapping and Software, Integration, Analvsis, Project Management, and 
Deployment Plans ■' » 



PROJECT 95NAV 012 
.VLATERIAL SAFETY DATA SHEETS 

The law requires that the manufacturer provide a material safety data sheet (MSDS) for any of their 
P^vr * oo^^°"^•"^"§J^^^°"^ chemicals. The Defense Federal Acquisition Regulations Supplement 
(DF.ARS) requires that the services obtain an MSDS with each procurement of hazardous material 
There are other DOD business rules that require the MSDSs to be submitted by the procurement officials 
to their service focal point. These focal points have industrial hygienists review the "paper" MSDSs 
This review consist of weeding out duplicates, quality control, and adding data such as logistics related 
mtormation. The manufacturers MSDS are then rewritten to conform to the DOD format When this 
conversion has been completed the information is placed on a floppy disk and mailed to DODs Material 
batetv Data Sheets Central Repository. These steps are labor intensive and cause delavs in ^ettine the 
material safety data sheets to the users of the products - » & 

The current practice is for the vendors and/or manufacturers to submit the safety data sheets by mail in 
?^ ^°I!?5^^Jiat they the vendor, are most familiar. The change in the simplified acquisition threshold 
trom 52D,000 to SIOO.OOO has led to an increase in the use of individual purchases by the buvint' 
activities. The net effect is an increase in the volume of individual material safety data sheets belns 
received at the cenu-al control point. The current paper treadmill system is overburdened and oettino 
increasingly slower in aening the MSDS to the users. ° 
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With the connnmng industry interest and participation in this effort it will result in the focal points being 
able to receive electronically transmitted and structured MSDS. When fully implemented wiSi a license 
plate, which IS a Umversal Product Code (UPC), to link the product to the MSDS, it will reduce the 
current processmg costs by approximately 50 % and allow the industrial hygienist to focus more on their 
dSd itSSS"'^' ""^^^ movement of hazardous material wiSin 

PSA: Logistics/Environmental Security 

Lead DoD EC/EDI PM: Navy, POC George Ganak 
(703)607-0245 / » 

Transaction Sets: 848 MSDS 
997 Acknowledgment 

Status: Prototype 

Mtiated development of data model for MSDS exchange between DoD and contractors. MSDS EC 
Strategic Plan, (50% complete) Development of Trading Partner Toolkit, Complete Strategic Plan, 
S^afto^SDS EDI^^' ^ '"^ application of Standard GenerJized Mark-Up 
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APPENDIX G - DOD AGENCIES 



1.0 DLA (POC DLA/MMPRS) 

1.1 Bacl^ound 

DLA maintains five (soon to be four) inventory control points which are responsible for purchasine 
fnSi^f.^ n ^5^"l§ 'P^"n^ commodities. Each center has a requirement to exchange infonnation 
mtemai to DOD and additionally to conduct busmess with commercial vendors and suppliers 

Prior to the development of the DOD EDI infrastructure, DLA used the capabilities and services of the 
Defense Automatic Addressing System Center (DAASC) to enable the implementation of EDI for the 
Agency, hxhibit G.l - DLA Architecmre, provides a pictorial representation of the curont architecture. 

DLA Architecture 



T»SC 
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Exhibit G. 1 - DLA Architecture 

The Defense Automatic Addressing System Center (DAASC), which is located in Dayton, OH and 
Tracy, CA, currently supports the following major DLA EDI requirements: 

• Routing of Military Standard (^^LS) formatted information among DOD entities 

• Conversion of the MILS data to XI 2 transaction sets to conduct business with com 
industry. 

• Management of the trading partner database. 

• Access to approximately 20 plus commercial Value Added Networks (VANs) and Value ^dded 
Service (VAS) providers for blanket and small business set aside purchasing. 

• Setup and maintenance of Prime Vendor mailboxes. * 

• Provide Continuity of Operations (COOP) through munial backup. 

The majority of the materiel management, depot maintenance and distribution systems/applications are 
Defense Logistics Support Systems (DLSS). These fonnats are used not only to exchange information 
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SnSSr^ifc^T^&T^S -^^^^^ ^=-0 other 

outside of the DLSS/DAAS Jena. ^asportation, have several X12 programs being supported 

1.2 Requirements 

Each of DLA's organizations uses X12 to support the purchasing orocess- however nr a • 

with the recently redefined OTOTia^ DLA mli ^' '>"™"=?f.Pra<:ttces. Consistent 

through the D%. DLA S2 ^^^ni^ '^^cSZu^kT^t'i!^^ 
(procurement) traffic to the NEPs/ECPNs DLA and nr^A ,Tiii ^ to migrate all public 

ctmently connected with oAsSatfft'tp^^i'of c«iS^^ ™° 

MB) mWbe supported bytSfS TC^d (approaching 2 

1.3 Analysis and Considerations 

s°rpUeS'^:se'?SS'S^^^ ferr^n"^ ''■^"-"P^ 

prices. Often, EDI tnmsaaion excC« Je a^ oM,«e co*taS''SLTLt,«^^^ 
dictate business practices to all segmeits of the vendor cnm™foS^ iii^ realizes that DOD cannot 
choose to use industry accepted ifTi^ UeS of *rDODffS^rS ra ? '=°?^°<i>V specific vendors 
the non-standard ICs while Lcou^ging A^^'l:^^,^''^,':::^,^'^-"'^'' 

m!iirrr|''f5&lSp^^^^^^^ P-l-= oategoty (the 

the capabilities of the NEP iid ECPNfiS ord?r S alli^^Ae mit^^n?, '7''' ™* "^'^A » test 

^y^f;i?sTSr«etT^^^^^^ 

2.0 DeCA (POC DeCA) 

2.1 Background 

2.2 Requirements 
2.3-AnaIysis and Considerations 
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APPENDIX H - MILITARY SERVICES 



1.0 ARMY(POC Army) 

2.0 NAVY(POC Navy) 

3.0 AIR FORCE(POC USAF/SCTT) 

4.0 MARINE CORPS 
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APPEiNDIX I - FEDERAL CIVILIAN AGEiNCIES - 



1.0 FEDERAL PROCUREiVIENT(POC DUSD(AR)) 

1.1 Background 



The President's Management Council chartered the Federal Electronic Commerce Acquisition Team to 
develop the Federal electromc commerce architecture. The procurement community is implementins 
EDI usmg Streamlining Procurement Through Electronic Commerce as its blueprint 

One of the outcomes of the Federal Procurement Streamlining efforts was the establishment of the 
Federal Acquisition Network (FACNET). The FACNET is not, as is implied by its name, a physical 
hardware network, but rather a set of parameters, built along functional lines, to be used by Government 
and pnvate users when unplementing EDI. The FACNET is designed to: 

• Inform the public about Federal contracting opportunities 

• Outline the details of Government solicitations 

• Permit electronic subnaission of bids and proposals 

• Facilitate responses to questions about solicitations 

• Enhance the quality of data available about the acquisition process 

• Be accessible to anyone with access to a personal computer and a modem. 

1.2 Basic Requirements 

PgP'^f/f'^'^ "^iP^^j^f implementing EDI primarily for Small Purchase Procurement 

(over $2,dOO and under SlOO.OOO) using the DII to provide the "single face to industry " Other 
procurement activities are sending XI 2 transmissions but those are not using the DOD EDI architecture 
for transaction set distribution. The DII is available to and is being used by many federal agencies which 
have been certified by DOD to use it. These activities support 98% of the small purchase procuremems 
In addition, they support large procurements and many of the small purchases which are awarded to 
large and small contractors. 

As commercial vendors are continuously being registered to do business with the federal oovemment 
electronically, it is expected that the amount of test traffic will remain relatively constant and the amount 
of production traffic will continue to increase. 

The Electronic Commerce Acquisition Team (EGAT) recommended an acquisition architecture centered 
around a virtual network for delivenng standardized transactions to facilities accessible to value-added 
neuvorks (V.ANs) and other entities as well as for delivering transactions.Initiallv the A'^encies will 
connect through the DOD Network Entry Points (NEPs) for access to the VANs' The ECAT has 
recommended that other FederallyK)wned NEPs be established so the Agencies will have a choice of 
connections into the Virtual Network. 

13 Analysis and ConsideratioDS 

The EGA PMO has agreed to use the N-EP portion of the DOD EC and EDI Infrastructure for VAN 
connections. It has allowed agencies to establish their own EDI gatewavs and intemal and external 
commumcations suppon. ' 

The ECA PMO has encouraged regular contact with the DIS A Center for Standards Mana«»ement 
Lommmee to resolve IC conflicts and to develop government-wide ICs. * 

Some Agencies have implemented EDI diff-eremly from other Agencies. Even within the same A<>ency 
operating at different locations, EDI is implemented differently. Individual agencies are permitted to use 
multiple gateways, runnmg on diff-erent hardware, software, and use different ICs to exchange the same 
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types of X12 tr^sactions. This has required the DOD EC and EDI Infrastructure to develop multiple 
ways to handle Federal sites. Federal sites must establish standard ways to provide ^ite information in a 
timely fashion to the DOD, NEPs and certified VANs. Stove-pipe implementations are developed 
without a consolidated agency approach. 





able of Contents 
DISA D7 Home Page 



PISA Home Page 



2 of 2 



1 1/13/96 8:28 A 



APPE^^DK W - DISA SUPPORT CAPABILITY 
(POC DISA - D7) 



1.0 DISA Support CapabUity 



Jus appendix descnbes the methods that DISA uses to provide EC and EDI support to its customers 
the Defense conunumty and the Federal civilian agency community. It is intended to be an evolving ' 
appendLX to the EC and EDI strategy document and will be updated periodically as new information 



becomes available. 

Tins appendix provides the need for EC in DOD, including a brief history of the events leading to 
today s.programs. It gives an overview of DISA's processes for gathering the requirements for customer 
support, and a high level view of the plan for maintaining and upgrading the DOD EC/EDI 
infrastructure. It also describes the environment to be used for developing new EC/EDI 
implementations, provides an overview of DISA's approach to EDI standards management, and 
discusses how the Global Combat Support System (GCSS) fits into the EC and EDI picture. 

1.1 Electronic Commerce 

Recent experiences in the DOD (e.g.. Medical Logistics) have proved the effectiveness of EC to rapidly 
procure cntical items, reduce costs, simplify business transactions, reduce paperwork decrease 
inventory, and mcrease transaction reliability. Despite its benefits, EC throughout the DOD is being 
unplemented through a multimde of Service and Agency initiatives with disparate directions DOD 
components use a variety of platfonns, processors, networks, and transaction data standards to conduct 
hC 1 he systems are stove-piped" and many use proprietary software and communications protocols 

u r^T^^"^^^^ electronically an industry trading parmer has to meet a different set of requirements for 
each DOD activity. Current efforts to solve these problems have focused on small purchase 
procurement. The scope of EC must be expanded to include govemment-to-government traffic as well as 
jaffic between government and mdustry trading partners for Contract Administration, Transportation 
bupply Management, Financial Management, Maintenance, and Engineering. 

EC/EDI has the potential for improving Federal Government operations, including our ability to sustain 
US forces, by su-earnlimng procurement, logistics, personnel, medical, transportation, financial, and 
reserve component functions. The GCSS EC/EDI product area provides common EC/EDI services and 
infi-astructure so that DOD fimctionals, and functionals in other Federal Agencies do not have to 
duplicate andpay for these capabilities individually. Common standards assure that EC^EDI applications 
used for combat support functions can interoperate with those used bv other Federal Atrencies and our 
trading partners in industry. ' * 

1.2 Electronic Commerce/Electronic Data Interchange 

This section wll begin with a brief summary of the background that led to the requirements for that 
portion of the DII needed to support the scope and objectives of EC/EDI. The next section will briefly 
S^^T^?- r cross-fimctional requirements process performed by DISA. It is followed by a focus on ie 
tC/EDI infrastructure upgrades and schedule. Discussions of the standards program and GCSS v^dll 
complete this appendix. 

1.3 Background 



On July 22, 1993, the Deputy Under Secretary of Defense (Acquisition Reform) chartered a Process 
Action Team (PAT) to assess existing capabilities to conduct DOD conu-acting actions usincr EC The 
teani found DOD components used a variety of platforms, processors, net^vorks, and transaction data 
stMdards to^conduct EC; the various systems were often stove-piped and manv used proprietary 
software and communications protocols. To do business electronically, an industrv trading parmer (a 
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commercial entity desiring to do electronic Commerce) had to meet a different set of requirements for 
each DOD activity. 

On December 20, 1993, the Secretary of Defense approved the PATs recommendation to initiate a 
24-month program to establish a DOD standard, centralized EC/EDI infrastructure. The Defense 
Information Systems Agency (DISA) was tasked to be the technical implementor of the PATs 
recommended architecture. 

Vice President Gores National Perforaiance Review mandated the establishment of a Federal 
Government-wide EC program for federal acquisition below a specified dollar threshold In response to 
this policy statement, the Federal Electronic Conunerce Process Action Team prescribed the use of 
DODs EC/EDI infrastructure for civilian Federal Government agencies. 

On June 23, 1995, the Assistant Secretary of Defense (Command, Control, Communications and 
InteUigence) mandated that the EC/EDI infrastructure support electronic business in all functional areas 
At that time, DISA was tasked to "establish, an EDI infrastructure implementation advisory group 
consisting of Military Services, Defense Agencies, and other appropriate participants, representing as a 
minimum, the functional areas of Procurement, Health, Finance, Human Resources, Logistics 
Environmental Security, and Reserve Affairs." 

Clearly, the scope of the EC/EDI project must encompass transactions beyond small purchase 
procurement, mcluding govemment-to-govemment traffic as well as traffic between government and 
industry tradmg partners. To efficiently accommodate electronic business for the expanded scope of 
functions, the EC/EDI infrastructtire will incorporate EC technologies beyond EDI. 

2.0 DISA Cross-Functional Requirements Gathering 

Exhibit W.l illustrates the elements involved in driving EC and EDI cross-functional infrastructure 
requu-ements. DOD and Federal functional customers are the prime generators of requirements DISA is 
the implementor of the requirements. The requirements process and its supporting structure is the 
methodology by which user needs are integrated into DII programs. To facilitate this process DISA/D7 
has integraupn managers assigned to assist functional customers at the CINCs, Services OSD and 
Agencies. 

The evolutioii of a requirement begins as depicted in E.xhibit W.l. By looking at the total customer need 
the ability to leverage data gathenng and provide a better integrated suite of products and services to the 
customer is improved. 
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Exhibit W. I - EC and ECI Requirements drivers 

Requirements are analyzed continually for their insertion into the design and development process 
Cross-ftmctional requirements that can quickly lead to improved interoperability are given priority' in the 
I'/?™ *e next section are the near term requirements that will lead to "an enhanced 

hC/EDI inirastructure. 

3.0 Infrastructure Upgrades and Schedule 

During FY96, the focus will be on phased development of the ECPN operations consolidating the NEP 
and gateway ftmctionahty. Other activities will be integration and continued development of the 
Contractor Registration System, program translators and the phased elimination of the gateways and 
phased commumcauon media transfer. Once all of the workload is transitioned to the new architecture 
tuture infrastructure upgrades will coincide with the identification and validation of the requirements in 
each of the new business areas projected to use the EC/EDI infrastructure. A list of past and future 
upgrades follows: . 

First Quarter FY96 
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Hardware delivery/configuration of new ECPN architecture at SUdeU, Columbus and Ogden 
Establishment of engineering developmental site 

Network management, relational databases, automated auditing, rudimentary error processing 
Second Quarter FY96 
Formal Testing of ECPN software version 1.0 
Development of operational manuals/training materials 

Configuration management of operational infrastructure configuration 
Operator Training 

Provide hardware/software tools to CSC for on-line transaction status 

ECPN software installation 

User/operator acceptance testing of architecture 

FOC of ECPN software version 1.0 

Elimination of SAACONs/AF gateways, consolidation of fimctionality into ECPN 

Software development of enhanced error processing, integrated archival database/ofif-line transaction 

SIOFa^C 

CCR initial ECPN integration 
Third Quarter FY96 

Elimination of remaining gateways 

Development of version 1.2 

CCR fully integrated into ECPN 

Automated workload allocation system 
Fourth Quarter FY96 through FY97 

Software enhancement for identified customer requirements 

Hardware capacity upgrades 

Mass data storage capability 

Transfer of new functional areas onto the infrastructure 
Version 2.0 of enhanced software 
FY98 

Capacity upgrades as required 
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Continued requirements validation of new functional areas 

Software development of ECPN functionality to meet additional requirements 



FY99-00 



Continued software development to meet changing/evolving customer requirements 
Exhibit W.2 below summarizes the EC/EDI Product Area Schedule. 




4.0 Development Environment 

?o^S;?T'^7r'°?i'"^ for new or transitioned EC and EDI projects will be the DISA 

Compliance Test Facility Electronic Commerce Processing Node at Slidell, LA. DISA will provide the 
configuration control necessary to ensure that implementations under development will be isolated from 
the production environment and that they are created according to the agreed upon specifications 
Special tracking and testing will be performed when developing cross-fonctional EC and EDI ' 
implementations. 

5.0 Standards 

^i?Wn n?lA° rd^^^niT^"^^^^^ information technology (IT) standards and conventions. 
\V thin DISA, the Center for Standards, pan of the Joint Interoperability and Engineering Organization 

n^S^FSSt°^^T'^f/ ?f ^'^.^^^ '^^'^ Implementation CoSJJfntiol^C^sr 

SSi^S?ti'o?!nXe^^^^ publicaL/and 

5.1 Standards Management 

Since the purpose of an EDI implementation is to exchange EDI information among disparate 
n^.r^Sfn'!!? A ,'?J"'^'u entitics stiict Conformance to broadly agreed information technoloey stkdards is 
paramount Although manv Mihtary Services and Defense Agencies use standards to conduct business 
crit?carneed '"pnS mn^r n^'f ot Standards usage throughout the Department of Defense remains a 
cntical need. For the most pan, .Amencan businesses use. or p an to use, the American National 
Standards Institute (ANSI) Accredited Standards Committee (ASC) X12 stLX^f^ excC ing data 

Sds for'S S:"(5?-f?ir" '''''' of standSSs Sfd D^ft 



5 of? 



11/13/96 8:29 A 



When implementing EDI, many factors must be considered, including: the Federal Information 
Processmg Standards (FIPS), the X12 Standards process, the migration of X12 to EDIFACT and the 
role of a smgle set of Federal Implementation Conventions (ICs). 

5 J. Implementation Conventions 

EDI Syntax standards, both X12 and EDIFACT. are intended to accommodate a full range of business 
acnvmes for all indusmes They are developed by consensus among a large number of iSers, each with 
his/her own set of needs. "Rie resultmg standard is very broad and is intended to meet the diveree 
requirements of all users. The DISA Center for Standards provides the management structure and 
mechamsms necessary to coordinate functional and technical efforts to tailor existing standards into 
documented DOD Implementation Conventions for use within a particular operational environment 
Business functionality is the preeminent requirement of EDI IT Standards and functional (business area^ 
participation m the standards process is required for the successful application of DOD EC and EDI 
S nS? sponsor fimctional participation through PSA working groups that cooperate 

with the DISA Center for Standards m the standards process. oo r f 

53 Federal Information Processing Standard (FIPS) 161-2 Praft). 

FIPS 9^?Lm^ F?P^^p?m ,^ f oT'^^" those adopted by the Federal Government via 

FIPS PUB 161-2 (Draft). FIPS pUB 161-2 does not mandate the implementation of EDI systems within 
the Federal Government; it requires the adoption of two families of information syntax standards. The 
two syntax standards are the X12 for domestic information exchanges and United Nations Electronic 
Data Interchange For AdmimstraUon, Commerce and Transport (EDIFACT) for international 
iniormation exchanges. 

5.4 ANSI Accredited Standards Committee X12 

Although a number of industry specific syntax standards for the electronic exchange of business 
information exist X12, accredited by ANSI, is generally recognized as the North American EDI 
standard and is well supported in a number of Pacific Rim nations. Most industry specific standards have 
committed to digning themselves widi XI2. Federal Agencies which were using industry specific 
standards on jO September 1991 may continue to do so for five years from that date. Industry specific 
standards may be used beyond five years only if no equivalent X12 (or EDIFACT) standard is approved 
by jO September 1 996. X12 consists of a number of underlying standards and addresses a wide ran^e of 
tV^'"cSrr A^'J^.'-?-^ ^[""^^ ""^^^ ^21 information exchanges are domestic and X12 is more matur'e 
han EDIFACT, X12 is the pnmary EDI syntax for the DOD. Management of X12 is accomplished 
through a number of fimctionally oriented sub-committees. A close working relationship between 
individual DOD members and these sub-committees has evolved and it is in the DOD's best interest to 
maintain these relationships. DOD participation in X12 sub-committees generally comes from a wide 
range of functional users. 

^rE^n^rT^-? ^° ^PP'°y^ ^ technical migration to and administrative alignment with 

UN/EDIFACT. New efforts are underway to merge the XI 2 standards into those of EDIFACT The two 
d^^^^^T^f^^fJ^T^ during this transition. The DOD, through X12, is participating in the 
development of EDIFACT message which will be required to trade with international partners. 

6.0GCSS 

The Global Combat Support System (GCSS) initiative deals with providing a common infrastructure for 
co-existence and mteroperation of automated information systems, or functional applications, providing 
combat support This environment is also to be interoperable with the Global Command and Control ' 
system (GCCS). The functional applications are being developed by various central design activities 
belongmg to the Services and Agencies, on behalf of the Principal Staff Assistants havini oversight of 
fhl'^'^c?°''^ ^"""f^ work of GCSS therefore consists of preparing common components of 

the mfi^tructure and helping the central design activities interface the functional applications to that 
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infrastructure. 



The firet of the five GCSS product areas, Functional Applications, deals with defining what is required 
to interface an application to GCSS and with any modification(s) required to the application itself. 
Modificauons to apphcations that are necessary to operate on a common infrastructure to include' 
cominon services, shared data, communications, and common hardware platforms fall 'under this product 
t^^l- of f^o^fications requked will vary by application and will be defined and scheduled to 
match the functional requirements for fielding the applications. »^ucumcu to 

pe other four product areas deal with providing for or modifying the common infrastructure so the 
functional applicatton can operate with it The EC/EDI product area provides common services and 
infrastructure for this service area so that each fimctional area does not have to repeatedly develoo and 
pay for these capabilities. As long as each application provides data in a commonly defined fashion it is 
assured logical as well as physical interface with other Government applications and with EC/EDI ' 
trading parmers m Industry. The Common Operating Environment (COE) product area is an area that 
complements modifications done to the application. While the application may be modified to run on the 
COE, it IS possible the COE may lack some services required by multiple applications. Modifications on 
the application will be done under the Functional Applications product area while modifications to the 
COE would be done under the COE product area. 

Similarly, the shared data environment product area will provide the services and infrastructure 
necessary to facilitate and achieve shared data for each functional application. Any modifications needed 
for the application are done under the Functional Applications product area, but as more applications are 
integrated into GCSS, it is expected that modification and expansion of the underlying shied data 
environment wiU be necessary. Finally. EC/EDI. COE and a Shared Data Environment all need a 
communications ^d hardware mfirastructure which will be provided by the Communications and 
Computing Shared Infrastrucmre product area. This will provide an integration and testing facility for 
GCSS, communications upgrades to support GCSS traffic, and fund common hardware and sofhvare 
infirastrucmre necessary to facilitate the fielding of GCSS. Several methods will be used for this latter 

3X6^. 
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APPENDIX X -ISSUES / ACTIONS 
(P0CDISA-D7) 



This appendix documents the issues that have been identified during development of this strateev and 
recommends the actipn(s) that should be taken to resolve the issues^The issSes ^e iSiStab^ 
format on the foUowmg pages. k^^'^'^iucu m uxoie 

The foUovong toble is a list of issues or requirements and one or more related actions to be taken The 
meamng of each table column is: ^"^ 
Org The organization about which the issue is concerned. 
Issue The issue, stated as a problem or as a requirement. 

Action A specific and measurable action designed to resolve the issue. 
Action Org The organization(s) responsible for the action. 
CompI Date The expected completion date for the action. 

Action Type (P)olicy, (O)perations, (QBE) Overcome By Events, or somethina else 
Tune Frame Near, Mid, or Long Term do we need this now - with date? * 



Org 


Issue 


Action 


Action Org 


DFAS 


1. DFAS HQ has agreed to 
implement EDI for unmatched 
disbursements using the DOD 
EC and EDI Infrastructure. 


l.a Monitor progress of the 
implementation. 




- 1 


2. DISA must ensure the 
ECPN architecture is prepared 
to handle 

govemment-to-govemment 
exchange of transactions^ and 
is able to replicate and 
correctly address one 
transaction to multiple 
locations. Until the ECPN is 
deployed, the current DISA 
gateways must accommodate 
DFAS' requirements. 


2.a Develop routing tables to 
accommodate the requirement 
of one transaction to multiple 
locations. 






3. There is a requirement for 
govemmeni-to-govemment 
exchange of EDI 850s 
(contracts) and 860s (contract 
modifications) in XI 2 version 
3050 for major weapon system 
procurement The 
requirements must be collected 
with enough lead lime to 
complete DOD EC and EDI 
Infrastructure enhancements 
well before DFAS milestones. 


3. a Develop the functional 
requirements for 850s and 
860s. 


DISA D7 
DFAS 
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4. There is a requirement to 
develop functional 
requirements for the capability 
to send single transactions to 
multiple locations. The 
requirements must be collected 
with enough lead time to 
complete DOD EC and EDI 
Inrrastructure enhancements 
well before DFAS milestones. 


4.a Develop the tunctional 
requirements for one to many 
transaction distribution. 


DISA D7 
. DFAS 




5. There is a requirement to 
develop functional 
requirements for the capability 
to pay the vendor and send the 
XI 2 820 Remittance Advice to 
the Department of the 
Treasury. The requirements 
must be collected with enough 
lead time to complete DOD 
EC and EDI Infrastructure 
enhancements well before 
DFAS milestones. 


5. a Develop the functional 
requirements for vendor pay 
and Remittance Advice. 


DISA D7 
DFAS 


USTRANSCOM 


6. There is a need for an 
analysis of DISN connections 
for all Defense transportation 
activities, and to provide ways 
to connect to DISN if activiues 
are not connected. 


6.a Perform an analysis of 
DISN connections. 


DISA 

USTRANSCOM 






6.b Provide DISN connections 
for activities that need it. 


DISA 

USTRANSCOM 




7. There is a need to conduct a 
transportation-specific ECPN 
performance/throughput/speed 
of service test and to develop 
requirements to begin the 
transition of EDI traffic from 
its commercial VAN 
connections to the 
Infrastructure's VAN 
connections. 


7.a Conduct ECPN 
performance tests. 


DISA 

USTRANSCOM 






7.b Develop requirements for 
transition to infrastructure 
VAN connections 


DISA USTRANSC 




8. There is a need to gather 
transportation industry 
encryption and 
non-repudiation security 
requirements and to 
incorporate Global 
Transportation Network 

LIS) services ana support 
into the GCSS. 


8. a Gather security 
requirements 


DISA GCSS PMO 
USTRANSCOM 
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8.b Incorporate GTN services 
and support into the GCSS. 


DISA GCSS PMO 
USTRANSCOM 




9. There is a need to 
incorporate transportation 
industry-specific data 
requirements into the Federal 
X12ICS 


9.a Update the Federal X12 
ICs transportation 
requirements. 


USTRANSCOM DI 
Center for Standards 


Medical 
Logistics 


10. There is a need for Medical 
Logistics to begin using the 
DOD EC and EDI 
Infirastructure. 


lO.a Collect Medical Logistics 
functional requirements. 


DISA 

Medical T oo'i^tir^ 






lO.b Perform testing of 
performance/throu^put/speed 
of service. 


DISA 

Medical Logistics 






1 0.c Develop Medical 
Logistics EDI deployment 
plan. 








lO.d Medical Logistics begin 
sendmg EDI traffic to the 
Infiastructure 


DISA 

Medical Logistics 




11. There is a need to 
incorporate Medical Logistics 
specific data requirements into 
the Federal X12 ICs 


1 La Update the Federal X12 
IC Medical Logistics 
requirements. 


Medical Logistics D 
Center for Standards 


DLA 


12. There is a need for DLA to 
begin using the DOD EC and 
EDI Infirastructure. 


12.a Collect DLA fimctional 
requirements. 


DISA 
DLA 






I2.b Perform testing of 
performance/throughput/speed 
of service. 


DISA 
DLA 






12.C Develop DLA EDI 
deployment plan. 


DISA 
DLA 






12.d Identify and certify VANs 
that DLA needs to use in the 
EDI infrastructure. 


DISA 






1 2.e DLA begin sending EDI 
traffic to the Infirastructure 


DISA 
DLA 




13. There is a need to 
incorporate DLA specific data 
requirements into tfie Federal 
X12ICS 


13.a Update the Federal X12 
IC DLA requirements. 


DLA 

DISA Center for 
Standards 




14. There is a need to 
transition DLA u^ading panner 
direct connections to 5ie EC 
and EDI Infiastructure. 


14.a Analyze DAASC value 
added services and 
functionality to determine how 
they can be added to the DOD 
EC and EDI Infrastructure. 


DISA 
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15. There is a need for DLA to 
use XI 2 version 3050 
transactions in the EDI 
Infrastructure. 


15. a Analyze methods to 
transition DLA translation 
sites to the ECPN gateways. 


DISA 






15.b Prepare the DOD EC and 
EDI Infi:astructure for DLA 
conversion to X12 version 
3050. 


DISA 


EGA PMO 


16. There is a need to write a 
Federal-wide EC and EDI 
strategic plan, help agencies 
present a unified requirement 
to ensure solutions are not 
stove-piped and that the 
solutions adhere to the Federal 
EC and EDI strategic plan. 
The EGA PMO needs to 
provide technical and 
functional POCs for each 
agency to coordinate all 
agency EDI implementations. 


16.a Write a Federal-wide EC 
and EDI strategic plan. 


DISA D7 can assist 
ECA PMO 






16.b Assist agencies to present 
a unified reauirement that 
adheres to the Federal EC and 
EDI strategic plan. 


DISA 






16.C Provide a technical and 
ftmctional POC for each 
agency to coordinate all 
agency EDI implementations 


ECA PMO 




17. There is a need to establish 
requirements for NEP access 
to the central Federal database, 
incorporate Federal NEPs into 
the DOD EC and EDI 
Infrastructure, and implement 
cross-functional EDI projects. 


17.a Establish requirements for 
NEP access to the central 
Federal database 


DISA D7 
ECA PMO 






1 7.b Incorporate Federal NEPs 
into the DOD EC and EDI 
Infiastructure 


DISA D7 
ECA PMO 






17.C Implement 
cross-fimctional EDI projects. 


DISAD7 
ECA PMO 




1 8. There is a need to enhance 
ECPN ftmctionality to meet 
requirements identified to 
DISA D7 and implement 
standard solutions in 
accordance with the ECA 
PMO strategic plans. 


18.a Enhance ECPN 
ftmctionality to meet 
requirements 


DISA 






18.b Implement standard 
solutions in accordance with 
its strategic plans. 


ECA PMO 
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There is a need to transition 
stovepiped EDI solutions to 
the standard solution. 


19.a Identify stovepiped EDI 
solutions that need to be 
moved to the new 
infrastructure. 


DiSA 
. ECA PMO 

■ 






19.b Develop and execute a 
plan for the transitions. 


DISA 

ECA PMO ' 


DISA 


Central Contractor 
Registration 


3/15-01: Corinne Engle will 
update the matrix to include 
the August 94 requirements as 
a requirements source and 
update any issues and actions 
as a result of this meeting. 








3/15-02: D6/EDS will provide 
Char Ivey an impact analysis 
(cost and schedule impacts) on 
processing multiple PLA loops 
in one 838 per day to D&B, 
and mclude the CGR ID and 
password in the request. 








3/15-03: Judy Monje/D&B 
will provide an 
analysis/proposal from D&B 
of what tum-around time can 
be expected under the current 
way CCR is doing business, 
i.e., one TP for each 838. 








3/15-04: A meeting with CCR 
and CTF needs to be held to 
define/refine the boundaries of 
responsibilities between CCR 
and CTF, including who will 
be responsible for notifying 
the TP of his confirmation. 








3/15-05: An MOA should 
establish and MOA with CTF 
that specifies the criteria for 
turn around times for CTF 
validation. This should include 
the terms for both before and 
after automation. 








3/15-06: D6/EDS will develop 
a proposal on how to send the 
notification of CTF validation. 








3/15-07: D6/DUSD(AR/EC) to 
get a "strawman" Errata 
3/IC3060 to CCR workgroup 
SO lunctional community can 
have input. 
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3/15-08: D3/D6/Gateway 
Administrators should 
establish a process to 
communicate with the gateway 
administrators. 


r 






3/15-09: The functional user oi 
the data pLSC?) should 
prepare instructions for the 
gateway administrator and 
AISs on how to use the data. 




■- 




3/15-10: Mike Smith to 
provide Charlene Ivey 2 cost 
estimates: 1) the spend plan 
and requirement for additional 
funds to continue the support 
to the PC program beyond the 
90 day time frame; and 2) a 
cost estimate for the 
development, redistribution 
and documentation for Errata 2 
of the PC program. 








3/15-1 IrDISA (D6ifeD7)to 
provide to Charlene Ivey the 
status of SOW deliverables, 
the dollars expended to date on 
each CCR SOW and the plan 
of action to contmue CCR 
development and funding. - 








3/15-12: D6/EDS to provide 
Charlene Ivey a cost and 
schedule estimate for the 
development of an on-line 
environment to support 50 
concurrent users. It was later 
agreed diat this estimate would 
include alternative 
technologies such as using the 
World Wide Web. This ^ 
proposal will also include the 
proposed screen designs. 








3/15-13: Charlene Ivey to 
provide Mike Smith with 
guidance on proceeding with 
the PC Program. 






1 


3/15-14: CTF (Lib Curtis) to 
test the PC program for Errata 

from Mike Smith. 
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3/15-15: EDS/D6 will provide 
handouts of the on-line 
registration screens to Mike 
Smith so he can get them to 
the CCR AWG members prior 
to the next meeting. These 
should be emailed to Mike 
Smith by 20 March. 








3/15-16: Deborah Germak will 
provide electronic copies of 
the PC software screens to all 
members of the CCR AWG 
via email. 








3/15-17: D6/EDS to provide 
Charlene Ivey a cost and 
schedule estimate for 
developing the SIC 
requirement 








3/15-18: Judy Monje to 
provide 3 copies of the SIC+2 
diskette to DISA-D6 (Mike 
Riha). 








3/15-19: Mike Riha and 
Deborah Germak v^U jointly 
develop a SOW for follow-on 
CCR development and present 
it to Charlene Ivey. 








3/15-20: D6 will develop 
technical alternatives to 
invalid DUNS that are 
validated by D&B and present 
them to Char Ivey for a 
decision. 








3/15-21: D6/EDS/Charlene 
Ivey will sit down and discuss 
D6's proposed predefined 
queries that are based on FOIA 
data. The proposal will be part 
of the 29 March proposal from 
D6. 


• 






3/15-22: Jim Gordy will 
consolidate the results of the 
Dec 5-6 and 20 CCR splinter 
group technical requirements 
and the geographic query 
requirements and the results of 
any other previous meetings, 
and any required DISA input 
into answers for the 5 page 
questionnaire. 
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3/15-23: DUSD(ARyEC) will 
raise the issue of data access 
and usage to Mr. Kelman's 
task force. 








3/15-24: D6/EDS to propose a 
solution that includes the 
DUNS and a password to 
verify a TP's 

access/modification request on 
his CCR profile. This proposal 
shall also include any request 
for support to process the 
mailingof passwords to TPs. 








3/15-25: Charlene Ivey will 
propose words for the VL A 
that V ANs must release the 
TPINs to the TPs and that the 
TPIN is the property of the TP. 
Also note that confidentiality 
of the TPIN must be assured. 








3/15-26: Charlene Ivey will set 
up a meeting between the 
DUSD(AR/EC) office and the 
federal EGA PMO to discuss 
details about federal 
organizations registering in 
CCR and the D6/EDS proposal 
for subphase 2. 








3/15-27: LESCO will send 
EDS a government registration 
for testing. 








3/15-28: The D6/EDS ^ 
proposal will include short 
range COOP/BEP solutions. 








3/15-29: D7 will research the 
21st century date codes in 
CCR for clarification of die 
problem. 








3/15-30: DUSD(AR/EC) will 
get authorization for the Navy 
to modify AISs for joint TP 
profile downloading 
capabilities for reportmg 
purposes. 




Army 




1) Action Item: Research 
waiver to FAR clauses that 
impact FACNET. 


ODUSD(AR/EC) 






2) Action Item: Provide Lt 
Col Walsh with an electronic 
copy of the ECIC Strategy 
Plan. 


ODUSD(AR/EC) 
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3) Action Item:. Follow-up on 
the Bell Atlantic D.O. 
implementation 


0PUSD(AR/EC)/D 






4) Action Item: Follow-up on 
equipment storage that is being 
used in Bosnia effort. 


ODUSD(AR/EC) 






5) Action Item: Provide 
follow-up information on CCR 
effort. 




Navy 




6) Action Item:^ Provide Navy 
the information promised at 
the DISA 12/95 functional 
users meeting. 


D2/D7 






7) Action Item: Conduct 
conference call to understand 
the services requirement on 
ECPN implementation issues 
and the impact to the 3050 and 
2003. 


D7 






8) Action Item: Manually 
scanning of error files to find 
transactions is a problem. 
Explore the possibility of 
automating a red flag" of error 
files. 


D3 






9) Action Item: Communicate 
an understanding of ECPN to 
the services (customers) or 
continuous customer 
education. 


DISA 






10) Action Item: CCR 

Interface operations manual 
will DISA prepare this? If so, 
then the Navy wishes to be 

involved in this process. 


DISA 






11) Action Item: Can the 
trading partner profile 
information be downloaded 
from the CCR in the ECPN 
environment in the future and 
in the present architecture? 


DISA 






12) Action Item: What is level 
of testing is currently being 
tested on the VANs and VAS 
(end to end testing)? 


DISA 






13) Action Item: Provide the 
Mr Nielsen a copy of the 
software svstem used to sort 
Trouble Tickets?(DIS A) 


D3 
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14) Action Item: Is there a 
way for a customer to check 
the status of Trouble Tickets? 








15) Action Item: DISA and 
Navy put together a 
implementation plan for Kings 
Bay, GA. Navy provide DISA 
their definition for flawless 
implementation. 


NAVY AND DISA 






16) Action Item: Establish 
policy issue on the VANs don't 
keep the original RFQ record 
and don't know what 
transactions sets have been 
sent or to whom received 
them. This issue is regarding 
amendments to solicitations 
and whether they should be 
canceled and a new solicitation 
issued each time there is a 
change to the solicitation since 
many VANsA^ASs do not 
offer the service of tracking 
RFQ numbers. Provide regular 
updates to Navy and 
components. This is important 
to the AIS users. • 


ODUSD(AR/EC) 






17) Action Item: How can we 
educate vendors on which 
convention to leam (3050 or 
2003)? DISA Provide 
guidance. 


DISA 






18) Action Item: Provide 
procedures or software that 
will enable the Navy ECIC 
representatives to DECODE 
DISA word processing 
attachments from their E-mail. 


DISA 






19) Action Item: Will DISA 
or the services test 
requirements on 3050 with 
trading partners? 


DISA 






20) Action Item: Is the ECPN 
dates given (February 15, 
1996) still valid? 


DISA 






21) Action Item: DISA set-up 
teleconference with customers 
on the 3050 and 2003 testing. 


DISA 






22) Action Item: Navy wants 
more information on the query 
capaouiiy inai ine tv^riN 
implementation can provide. 


DISA 
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23) Action Item: Establish 
policy issues on VANs 
umiaieraiiy removing clauses 
that pertain to an Rf Q. 


Ui;uSD(AR/EC) 






24) Action Item: Trading 
Partner Profile functionality 
currently ai tne (jateway part 
of ECPN functionality? 


DISA 






25) Action Item Navy 
requested information about 
uie ojo status, mcluding 
ERRATA 2. 


DISA 


Air Force 




1 . Arrange for a separate 
meeting with AF to discuss 
and resolve transition of the 
Wright Patterson AFB 
workload onto the ECPN 
without AF Gateway support 
or decide that AF must add an 
aaaiiionai uateway to support 
the volume of workload 


DISA 






z. rroviae loilow-up 
information on CCR effort. 


DISA 




•I 


j. Arrange a separate meeting 
with component 
representatives on CCR status. 


UDUSD(AR/EC) 
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APPE^^DIX Y -REFERENCES 

(POC DISA - D7) 



ms appendix lists vanous documents, working groups and action teams that are or have been involved 
m the Federal government's efforts to identiiy and resolve problems through tSiS)WnS^Zf 
Electromc Commerce. Each tem contains a synoosis of the effort anHinfiSLo J^TTil * u ■ 
access to it. Readers of this document^encSS to ^onMbSe^o 

inputs to Mr. Jim Mulder at the address giveSe1o^5 to^l^ do« ^""'^"^ ^^"""^^ 



ITEM/ SYNOPSIS 
LOCATION 



dt^Z'!mii''T"'u if^?«//;eme«/s, Systems, and Implementation Strategy 

www.disa.mil/D7/onInpubs/strategy/index.html *^ 

ftS^^'^^? ^ " DOD EC vision by defining requirements, roles and responsibilities and 
strategies for achievmg a umfied approach to EC implementation and operatioA iTaddS ^serves 
to documen the current and fumre capabilities of the Defense InformationSyJJeim A^^^^ 

3vf "^"^"^^ Defense InfoimatirSS^ m^m [tS^S ^ 

evolvmg document that is mtended to be updated periodically to ident^TdWsIn remiri^ .r.A 
the strategies that need to be tailored to fulfill those reqmremente ^ ^ reqmrements and 



Not available until finalized 

USnfAS-SfniTi fl^T^ T from the Under Secretary of Defense (Acquisition & Technology) 
^nSx^S^Jt^^!^^^^ Communications &''^^*°Sy) 



So'JaVteu^dlTn— 

Prescribes an aggressive plan to accelerate the pace of EDI implementation in suoDort of 
SS'Snnn ^"^^"^ ^"'T'''^ ^"^^^y. attention and resources toCd expS3fn° EDI uses in 
support of pOD transportation business inforaiation exchanges. It identifies basirrSremenf. for th. 
use of EDI m support of DOD transportation in addition to detailing the ciLn^ES^^ 
Electronic Commerce in Contracting (ECIC) Process Action Team (PAT) Reoort 
Internet World Wide Web (http://.vw^v.acq.osd.mil/ec/IookupTml ^ ^ 
rp^hnoF.^^^ ^ '^n f °^ ^ •'0"0'^-"P review of existing and ongoing implementations of EDI 
technologies m Defense procuremem systems. Resulted in an impllmentation plali for ECIC. 



F ederal Acquisition Streamlining Act of 1994 ■ 

SBA On-line BBS 1-800-697-4636 as "Small Business Guide to Procurement Streamlinina. 

acqmsmons, promote electromc commwce. <md improve the efficiency of^r^ ^S.E 



Your Introduction to Electronic Commerce -A Handbook for Business 
Electronic Commerce Information Center 1-800-EDI.3414 or Internet World Wide Web 
(http://mvAv.acq.osd.mil/ec/subjects.htmI) 

Describes to businesses trading with the Federal government various feanires and procedures 
pertaining to Electromc Commerce as conducted bv the govemmem IncludesTDrimer o^^^ 

s^o^^vSfrfq^^rfJ'n^^'""^^^^ 
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Federal Electronic Commerce Acquisition Instructions (FECAI) ' 

SBA On-Une BBS 1-800-697-4636, or Interact World Wide Web 
(http.7/www.acq.osd.inil/ec/ecic_hpg.html 

These insmxctions explain how contractors register with the Federal government They describe the 
""^m^^V x ^ ^"^^^ ^S^^^o'^ S tabase to avoid repetitive registrations with 4ch procurement 
office It also covers standards value added service providers, electronic payments and financial 
institutions, and other topics related to domg electronic commerce with the Federal gov ernment. 

Federal Implementation Convention Guidelines 
1-800-334-3414 

Electronic Commerce/Electronic Data Interchange is conducted using national or international 
standards. As a rnatter of common practice, standards are seldom used in dieir entirety An 
Implementation Convention is a subset of a standard that conforms to the standard but only 
imp ements that portion of the standard that is applicable to the using organization! The Federal 
TfSl??^'^^^®? Convention Guidelines are based on the American National Standards Institute 
(ANSI) Accredited Standards Committee (ASC) XI 2. 



Defense Management Reports Decision (DMRD) 94 1 , 1 990 
Unknown 

Stated that the str^egic goal of DpD's current efforts is to provide the department with the capabiUty 
to mitiate, conduct, and maintam its external business related transactions and internal logistics 
contracung. and financial activities without requiring the use of hard c opy media. 

Defense Information Infrastructure (DII) Master Plan 
(703) 607-6342 PSN 327-), POC ILt Vincent Williams 

The DII Master Plan reflects DOD Components' collective strategy for providing the Warfighter with 
information capabilities to achieve mission success. The key purposes of the DII Mater plan are to- 
establish the common DOD vision of the DII to ensure unity Sf efforts in its achievemeni^idemify 
current and future elements of the DII; define roles, responsibilities and relationships for ^11 of DOD's 
DII participan^; identify the relationships and interdependencies of current DII initiatives; and assist 
m planning and implementing of DII effons across D OD. 

Defense Information Systems Agency Home Page 
Interact World Wide Web (http://www.itsi.disa.mil/ 

VT"^ of information including a listing of compliance tested software 
packages (/ct/soft/html) and a hstmg of compliance tested VASs (/ct/vas html) 
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APPENDIX Z - GLOSSARY 



TERM 


DEFINITION 


AIS 


Automated Infonnatioii System 


ANSI 


American National Standards Institute 


ARCC 


Acquisition Reforai Commimications Center 


AR/EC 


Acquisition Reform/Electronic Commerce 


ASC 


Accredited Standards Committee 


ASD(C3I) 


Assistant Secretary of Defense (C3I) 


C2 


Command and Control 


C3I 


Command, Control, Communications and Intelligence 


CCR 


Central Contractor Registration 


CDA 


Central Design Activity 


CFS 


Center For Standards 


CFSE 


Center for Systems Engineering 


CISS 


Center for Intormation Systems Security 


COE 


Common Operating Environment 


COOP 


Continuity of Operations 


COTS 


Commercial-Off-The-Shelf 


CSC 


Customer Service Center 


CTF 1 


Compliance Test Facility 


DBOF 


Defense Business Operations Fund 


DCTF 


DISA COOP and Test Facility 


DFAS 


Defense Finance and Accounting Service 


DII 


Defense Information Infrastructure 


DISA 


Defense Information Systems Agency 


DISN 


Defense Intormation Systems Network 


DLA 


Defense Logistics Agency 


DMC 


Defense MegaCenter 


DMLSS 


Defense Medical Logistics Standard Support 


DMS 


Defense Message System 


DOD 


Department of Defense 


DPCSC 


Defense Procurement Corporate Information Management Systems Center 


DUSD(.AR>'EC) 


Director tor Electronic Commerce 


DUSD(AR) 


Deputy Under Secretary of Defense (Acquisition Refonn) 




Electronic Commerce 


ECIG 


Electronic Commerce Intormation Center 


eck: 


Electronic Commerce in Contracting 
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ECPN 


Electronic Commerce Processing Node • . 


EDI 


Electronic Data Interchange 


EDIFACT 


EDI for Admimstration, Commerce and Transport 


EDISMC 


EDI Standards Management Committee 


EFT 


Electronic Funds Transfer 


FACNET 


Federal Acquisition Network 


FECAI 


Federal Electromc Commerce Acquisition Instructions 


FRD 


Functional Requirements Document 


FTP 


File Transfer Protocol 


GCCS 


Global Command and Control System 


GCSS 


Global Combat Support System 


GOTS 


Govemment-Off-The-Sheif 


GW 


Gateway 


IC 


Implementation Convention 


IOC 


Initial Operational Capability 


IPT 


Integrated Process Team 


IT 


Information Technology ~ 


JIEO 


Joint Interoperability Engineering Office | 


JITC 


Joint Interoperability Test Command '] 


JLSC 


Joint Logistics Support Center 1 


MHSS 


Military Health Services System 1 


iVULS 


Military Standard 1 


iVILFPIP 


Medical Logistical Process Improvement Procram 1 


NEP 


Nenvork Entry Point -] 


NIPRNET 


Non-classified Internet Protocol Router Network 1 


OSF 


Operational Support Facility \\ 


PAT 


Process Action Team — |j 


PSA 


Principal Staff Assistant 1| 


SMC 


Standards Management Committee — I 

• . 1 


SPS 


Standard Procurement System " 


TDCC 


Transportation Data Coordinating Committee | 


TP 


Trading Parmer 




URL 


Uniform Resource Locater 




USD(A&T) 


Under Secretary of Defense (Acquisition & Technoloev) 




USTCJ4-LT 


US TR^^NSCOM J4-LT 


VAN 


Value Added Network | 


WWW 


World Wide Web HI 



2 of 3 



1 1/13/96 8:35 / 



'able of Content's 



I PISA D7 Home Page 
I PISA Home Page 



